Handling of Etag in NSUrlConnection seems to be kind of random

267 views Asked by At

Setup

In our current project we us AFNetworking (based on Foundation URL Loading System). Everything works fine so far.

Theory

Recently we introduced ETag in the response header, which should be handled be NSURLConnection (means the Foundation URL Loading System) by default. The received ETag value (from the response) should be included in the next request header as 'If-None-Match'. That's the theory.
In practise, our ETag is an integer and our backend increases this integer on every valid request and sends this increased value in the response header.
In the client we changed nothing and checked the request and response headers with charles. We do not plan to integrate some caching, we are only interested in the ETag value handling.

Results

The results are really strange. For the first requests (about 10 requests) no 'If-None-Match' header field was set. After this period everything is okay for some requests. The last received ETag value is send in the 'If-None-Match' header field of the next request. Then after around 30 requests the value in the 'If-None-Match' header field is not an assumed value. For example, the last received ETag value is 38 and the 'If-None-Match' value in the request is 8.

| Request (If-None-Match)| Response (ETag)  | Expected |
| ---------------------- |------------------|----------|
|                        | 1                | YES      |  
|                        | 2                | NO!      |
|                        | 3                | NO!      |
| ...                    | ...              | ...      |
| 11                     | 12               | YES      |
| 12                     | 13               | YES      |
| 13                     | 14               | YES      |
| ...                    | ...              | ...      |
| 30                     | 31               | YES      |
| 8                      | ?                | NO!      |

Question

Has anyone experience or knowledge about how ETags are handled in NSURLConnection (means the Foundation URL Loading System) and why we see these strange results?
Or even more direct, has anyone some tips and practise how to solve the issue? Do we need to set some specific values for NSURLCache or something related?

0

There are 0 answers