I can not for the life of me find any documentation regarding the possible properties of varnish (version 3) objects.
We know (from googling, varnish documentation just mumbles and leaves you more frustrated) for example that the request object has the url property (req.url) and also that it has req.http.X-Forwarded-For. But has anyone ever in any way found... say... a list?
Thanks!
/joakim
You can't really give a comprehensive list of things like req.http.X-Forwarded-For because req.http.* are HTTP headers. The Cookie header of a request will be req.http.Cookie and the User-Agent header will be req.http.User-Agent. There are a lot of standard headers, but you can set any arbitrary header and it will show up in req.http.___________. You can see the headers of the HTTP response in resp.http.*. Same for backend response in beresp.http.*.
All of the other properties are listed here: https://www.varnish-cache.org/docs/3.0/reference/vcl.html#variables
Related
This has me baffled.
I can request the document content as base64 with curl , no problem.
curl https://demo.docusign.net/restapi/v2/accounts/<id>/envelopes/<id>/documents<id> -H"Authorization : Bearer <token>" -H "Content-Transfer-Encoding: base64" -o <filename>
Return headers are
Content-Disposition: file; filename="blah"; documentid="1"
Content-Transfer-Encoding: base64
and the file is returned in base64 format.
Using the Apache oltu oauth2 library which underneath uses HttpURLConnection I cannot get the response to be sent in base 64. I have the request headers set to
Content-Transfer-Encoding: base64
Accept : */*
Authorisation : Bearer <token>
But all I ever get back is the binary version of the file which ultimately bombs out because the library saves the stream as a string which screws up the pdf.
I can't trace the return header , but the request header definitely has the above fields set.
Is there anything in the Docusign endpoints which look at the User-Agent or anything else to determine whether to do the base 64 encoding ? Why else would it only ever return the binary stream ?
I suspect your Java output is not the same and the best way to confirm this is to capture exact JSON/SOAP request posted by your API calls via Java to DocuSign by following steps explained at this DocuSign support article https://support.docusign.com/guides/ndse-user-guide-api-request-logging
Please post these and I am sure it will be we will be able to deduce the library "add" that is changing the actual output.
OK thanks #david for the advice on logging the requests in docusign. I find that the "Transfer-Content-Encoding" header has mysteriously disappeared on arrival at the Docusign server. Some digging indicates that
a. this header is dodgy anyway for non-email uses and that
b. in the Java HttpUrlConnection class it is "removed" as security measure. You can apparently set some flags to revert to previous behaviour. See https://bugs.openjdk.java.net/browse/JDK-6996110
In any case I worked around the problem by implementing a class which reads the response as an InputStream and not worrying about base64.
Hopefully this helps a Java OAuth library user save a day of their lives banging their heads against a wall !
I am new to Jmeter please help me in this, i try to do performance test of my nodejs application.And i have one api, for this i have to pass parameters as well as post from .csv file but i am not able to achieve so give your valuable input
Put your parameters to "Path" input field
Put your request body to "Body Data" input field
You might also need to add a HTTP Header Manager and configure it to send Content-Type header with the value of application/json. See REST API Testing - How to Do it Right for more details.
I have searched a lot and still couldn't find a solution, I am using nodejs with express which is setting etag to true by default, I tried all of the solutions i found online and it is still set, examples:
res.set('etag', false);
res.removeHeader('ETag');
app.disable('etag');
app.use(express.static(__dirname + '/public'), { etag: false });
And still it is set, so, is there something i am missing here since i am not really that experienced in node or express.
My question is obviously, how to disable this header, because, I have a page with a lot of images (A LOT) and all of them are static and etag is causing a lot of blocking since it's sending requests to check validity and preventing the browser from relying on cache-control, which is hugely increasing page load time.
Thanks for the help
Refer to: http://expressjs.com/4x/api.html#app.set
You can do it in ExpressJS 4 using:
app.set('etag', false);
Setting it to false disables the etag header altogether while the default is set to true.
Possible option values are:
Boolean (true,false)
String ('strong', 'weak')
Function
This is not a full answer but I am adding it just in case anyone faces the same issue.
It turned out what I was missing is that the browser forces a cache validity check on first load (including page refresh), and that's why I kept seeing the etag header.
To properly test if the header is removed you have to browse to the url and check not go directly to it.
I hope this helps someone, because it took me a while to find it out
IOwinContext does not appear to have the HTTP Referrer in it, and I need to grab it. What is the right way to get that particular variable? IOwinContext has several Typed PEMs but I don't see referer in particular.
The system I am working is self-hosted.
Thanks.
The OwinContext doesn't have 'HTTP Referer' as item in Request header. This has been renamed in Owin self host context. It's now known as 'Referer'. So once you have object of owin context you can get the information by using:
context.Request.Headers["Referer"]
Using ServiceStack 3.9.2x.
Out of the box (and as seen on the metadata page) service stack comes with built-in support for a bunch of content types - xml, json, jsv, etc. What is the best way to tell ServiceStack to limit the set of supported content. For example my service only knows how to speak JSON and I don't want ServiceStack to honor requests that sport "Content-type: application/xml" or "Accept: application/xml" headers. In said case I would like ServiceStack to respond with a 406 (Not Acceptable) response, ideally including in the body the set of supported content (per HTTP 1.1 spec).
Also how does ServiceStack decide what the default type of the content is for requests that do not sport an Accept or Content-Type header (I think I am seeing it render HTML now)? Is there a way to tell ServiceStack to assume a specific content type in these cases?
See this answer to find out how to set the default content type in ServiceStack: ServiceStack default format
You can use a Request Filter to detect the requested content type with:
httpReq.ResponseContentType
In your global request filter you can choose to allow it (do nothing) or write directly to the response, e.g. 406 with list of supported content as you wish.
ServiceStack order of operations
The Implementation architecture diagram shows a visual cue of the order of operations that happens in ServiceStack. Where:
EndointHostConfig.RawHttpHandlers are executed before anything else, i.e. returning any ASP.NET IHttpHandler by-passes ServiceStack completely.
The IAppHost.PreRequestFilters gets executed before the Request DTO is deserialized
Request Filter Attributes with Priority < 0 gets executed
Then any Global Request Filters get executed
Followed by Request Filter Attributes with Priority >= 0
Action Request Filters (New API only)
Then your Service is executed
Action Response Filters (New API only)
Followed by Response Filter Attributes with Priority < 0
Then Global Response Filters
Followed by Response Filter Attributes with Priority >= 0
Any time you close the Response in any of your filters, i.e. httpRes.Close() the processing of the response is short-circuited and no further processing is done on that request.