Im currently migrating an old Android application to use Retrofit2
Some of my HTTP calls are DELETEs
While testing I've found my HTTP DELETE calls work fine without Content-Type and Accept headers.
Does HTTP ignore these headers when performing DELETEs?
Is there a Best Practicefor always employing Content-Type & Accept headers?
Accept and Content-Type are used for deciding which representation of a resource should be sent in the response. With a DELETE there generally is no response body, and so there's nothing to decide.
To put it another way, DELETE operates on the entire resource, so there's no purpose in negotiating a specific representation.
Related
How do I make the tag carry the request header? I use the <a> tag to download. And I need to carry a token in the request header.
When you use a tag to download files or link to any document, in general, it is not possible to manipulate extra headers! Browsers will send the typical headers. To solve this problem, following are the alternative solutions.
Your token must be query parameter in the URL so that back-end server can read it.
Or you can use cookies to save the token and browser will ensure that cookies are sent for your request automatically. (For security, ensure that you cookie is HTTP only and rejects CORS requests)
Alternately, if you are not really after downloading the file or simply trying to show on browser, then you can use XHR or fetch where you are free to manipulate headers.
Have a single entry service which is acting like a facade/proxy service for downstream services. The service will need able to detect if the request is a "page request" or "api/xhr" request to perform error handling (302 redirection or 401).
So far have considered:
To use Accept header and detect text/html follow the following reference, can't tell if this is a good indicator to detect a page request
To introduce a custom header for all "api/xhr" request
To enforce all the "api/xhr" requests to follow a "/api" pattern (troublesome as for certain application the xhr is not a restful api)
Any good suggestions are welcome
Ended up using Option 1
Detect page request using Accept header with value "text/html"
As we do not use ajax for partial view
Usually the non-standard HTTP header X-Requested-With is used. Just the presence of the header should be enough. It has at least one advantage over Accept: It cannot be set on a cross-site request, which helps preventing CSRF.
Is it safe to assume that an HTTP request with an Origin header is a CORS request?
If not, what is the correct way to distinguish a CORS request from a regular HTTP request originating from, say, an PHP app on an external server?
If by “CORS request” you mean a cross-origin request—i.e. a request using the CORS protocol—then no, it isn’t safe to assume request with an Origin header is a cross-origin request.
That’s because, along with requiring browsers to send an Origin in all cross-origin requests that use the CORS protocol, the Fetch spec also requires browsers to send the Origin header for all requests whose method is neither GET nor HEAD:
If the CORS flag is set or httpRequest’s method is neither GET nor HEAD, then append Origin/httpRequest’s origin, serialized and UTF-8 encoded, to httpRequest’s header list.
So browsers must also send the Origin header for, e.g., all POST requests.
The Fetch spec further states:
A CORS request is an HTTP request that includes an Origin header. It cannot be reliably identified as participating in the CORS protocol as the Origin header is also included for all requests whose method is neither GET nor HEAD.
So the spec actually defines CORS request to mean “any request that has an Origin header“ — even if that request isn’t cross-origin and so doesn’t use the the CORS protocol.
That may seem like a weird way to define it, but anyway given that, it’s important to remember that anywhere else the spec mentions CORS request, it does not necessarily mean a cross-origin request or even “a request participating in the CORS protocol” — because per the above definition from the spec, a same-origin POST request is also a CORS request.
So, there’s no way from the server side to reliably identify a given request as participating in the CORS protocol. Only the browser sending the request knows—and other than Origin, there are no other headers we can assume browsers will always send in CORS-protocol requests.
Want to know where exactly data will be cached in Restful Webservices? Please avoid saying browsers cache Restful webservices data.
REST is based on HTTP.
In HTTP you do not know if you data is cached somewhere. It may be in the browser or in any node in between the client and the server.
However your REST-Server may add the Cache-Control HTTP header to its response, e.g. Cache-Control: No-Cache to mark the response as not to cache.
It is not assured if this will not be ignored by a proxy or whatever.
Your client can also request to not cache data. In jquery you just add cache: no to the AJAX-request and it will do the trick.
If jquery is not available you will have to use the if-modified-since header (http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#if-modified-since).
Probably this post cleared my doubt.
http://www.openlogic.com/wazi/bid/283625/Caching-web-service-results-can-enhance-Apache-application-performance.
I am using JMeter to test an HTTP server that accepts and validates an APIKey and returns a time limited token on success. I want to send a token if I have one and an APIKey if I don't so I have complementary If controllers each of which have HTTP Header Managers beneath them.
Neither HTTP Header manager is actioned.
By adding other components alongside the HTTP Header managers I can see that these are conditionally executed but the HTTP Header Managers are still ignored. If I copy an HTTP Header Manager up out of the If controller (to the same level as the HTTP Request) then is is acted upon.
Is this usage supposed to work? If not, is there a way to conditionally set HTTP headers that does work?
Do the following:
move the sampler inside each IfController
and move listeners outside of Thread Group (not related to issue)