I am setting cachePolicy on url request.
First call to an url (GET) return status code in 200.
Second call to the same url return 200.
If use a rest client i obtain for the first call 200, and for the second, with properly header ( If-None-Match) 304
Reading online i understand that iOS serialize first request with status code 200 and retrieve it for the second call.
There is a way to obtain 304 instead of 200 in UrlCache or understand if it the data came from cache and not from network.
From http://jonathanblog2000.blogspot.com/2017/07/ios-uiwebview-nsurlsession-cache.html :
If you want to test and verify the cache works properly in your app, you have to log the device http traffic, as the delegate of NSURLSession will never see the 304 status code returned from server, it will be automatically replaced by the status code in the cached response.
This is a good thing. This means your app can just pretend you got a successful response, and not worry about how the response was obtained or what sort of optimizations was happening. You just deal with the response the same way regardless of whether it was pulled from the cache or not.
Related
I don't know if it ever would, but if my server responded with HTTP status code 304, would the Fetch API (specifically response.ok) and axios.get() see the response as 200?
The documentation for both talk about the request being viewed as successful if the response code is in the range 200-299, but clearly 304 is outside this.
When a browser does a GET request with a If-Match or If-Modified-Since header, and the server responds with 304 Not Modified, the client will just see this as 200 OK.
The response is served from cache, instead of the server, and it allows the client (axios in your case) to not have to understand HTTP caching, but it can still take advantage of it.
I don't know what a client will do when they send a request without preconditions and still get a 304 response. A client wouldn't have an earlier cached response so this would definitely be 'broken'. I'd imagine you'd get an error but I'd be curious to see what.
No, they will both not see the response as 200.
While axios.get will return a promise rejection, the return value of response.ok when using fetch API will be false and response.redirected will be true.
I am specifically interested in whether a proxy server(or other http caches) caches the URI, Method, Headers and Body of the client's request? Or is it only URI and Method?
The reason is I am confused with negative caching, e.g. caching response with 400 status code ("Bad request"). I mean if the first response had an "invalid" body that caused the 400 error and we cache it does it mean that subsequent requests with a "valid" body will still get 400 response from the cache? (Without even hitting the Origin server?
The GET requests are the ones that can be cached by intermediary caches.
As shown in the book "HTTP: The definitive guide" only URL and headers get cached.
The PUT, POST and DELETE requests will cause the cache to be invalidated as shown here.
So my original question (about 400 response because of invalid body) was wrong since GET request should not have body according to REST and other methods (which could have body) cause the cache to be invalidated.
Thanks #Adrien for pointing at it!
I have a request from the client - when the user performs an action, there can be 3 actions:
the action succeeds with 200 OK status
the action fails (400) with an error message
the action succeeds but we need to display a helpful warning message to the user. This happens when the allocated amount is almost used up.
There does not seem to be a way for REST APIs to return an indication that the action completed successfully with some helpful information that further action might fail.
Thanks
HTTP response codes are limited and I think, those to be used to indicate any generic response. To have application specific response codes or response strings, it is better to have application level response codes to be communicated via HTTP response payload.
You didn't mention which HTTP method you are preparing for. Using GET should of course not modify anything, so I'm assuming it's either POST or PUT.
For POST, the response should be 201 Created. There should be a Location header line indicating the resource that was created.
For PUT, the response should be 200 OK.
In both cases, you can return a content body, as others suggested. This body can be some status information about the current state of whatever resource you are using. Note, that this status information might be reachable explicitly by some other URI, so it can share a mime-type with that "status" resource.
REST is using HTTP methods and HTTP status to represent the status of reply, by checking HTTP status I can find code 203 I think it could be suitable for your 3rd case :
203 Non-Authoritative Information (since HTTP/1.1)
The server successfully processed the request, but is returning information that may be from another source.
A PUT requests can have many outcomes, and I was wondering which status code would be best for each of them.
Say I want to create a new resources, so I do something like that:
PUT http://example.com/resources/resource-1
And I would get a HTTP 201 because a new resource has been created.
Now I want to update this resource, so I do the same request, with new contents:
PUT http://example.com/resources/resource-1
And I get HTTP 200 or HTTP 204, because the resource has been updated. But what if I send this request once again with the same contents? Should the server return HTTP 200 or HTTP 204 even if nothing has been updated?
I am aware that HTTP 200 and HTTP 204 both just mean that the request was successfully processed, and even if the data don't change the request can (and should) still be successfully processed. But is there a way to tell the client that the request has been successfully processed but nothing has changed on the server side? And if there is, should it be used for a PUT request? PUT being idempotent, should different status be returned depending on the actual processing on the server side (as long as no error occurs during this processing)?
But is there a way to tell the client that the request has been successfully processed but nothing has changed on the server side?
Yes, but that's not what status codes are for.
Either return 200 OK and a representation of the entity, or 204 No Content and return nothing.
For no change being applied, use a header like ETag. The client can compare the ETag with their previous value, and determine nothing was changed.
I have an iOS app in which a REST WebService request is made through NSURLConnection. It works fine in all cases except when the service (implemented with .NET - IIS 7) has no data to return. When it has no data, the response shows status 204 alright, and has an empty response body, but it takes a very long time (excess of 45-60 seconds) to trigger the connection:didReceiveResponse delegate.
I noticed that in the C# code, the status code is explicitly set to 204 in these cases, and "null" is returned (which I know is incorrect in itself: 204 responses should return nothing, not even null).
Debugging this WebService with Fiddler, I found a warning stating that there was a mismatch between the response-length header field (which had a value of '4', perhaps from "null"?), and the response-body, which of course was empty.
Now this whole issue (of the NSURLConnection delegates taking a long time to get triggered) was fixed when I stopped setting the status code to 204, but the strange part is, this only happened in my production environment, and not in the staging environment.
Is there any reasonable explanation for this? Perhaps some IIS setting?