CODEWITHSUNDEEP
iosswiftalamofire
Lee Kah Seng
Lee Kah Seng

Reputation: 183

Alamofire does not set `If-None-Match` header automatically

I have an iOS app that making API calls to 2 different servers (server A and server B) using Alamofire 5.2.2. Based on my understanding and what I read on StackOverflow, Alamofire should automatically set the If-None-Match request header as long as the cache policy is set to .useProtocolCachePolicy, and return status code 200 to the app if the server responded with status code 304.

I am able to make an API call to server A and Alamofire is setting the If-None-Match header as expected. However, by using the same set of code, Alamofire is not setting the If-None-Match header when I make API call to server B.

One thing I notice is that server A is using a strong validation:

Etag: "7266bc2f1b245365bb1a74da5185bca6"

Whereas, server B is using a weak validation:

ETag: W/"6672-pKPf8kg1eUMH8msoW0et1yskcQQ"

I also tried to manually set the If-None-Match header when calling server B and the server responded with status code 304. I was expecting Alamofire to return status code 200 to my app, instead, it returns status code 304.

Any idea why Alamofire does not automatically set the If-None-Match when making API call to server B? Is that an Alamofire bug or just a server config issue? Anything I can do to get the same behavior as making API call to server A?

Thanks in advance.

Upvotes: 1

Views: 541

Answers (2)

Lee Kah Seng
Lee Kah Seng

Reputation: 183

Apparently, the reason for my problem is because server B has the response header Cache-Control = no-store and Alamofire is respecting this header and ignore the given Etag.

Upvotes: 0

Jon Shier
Jon Shier

Reputation: 12790

A 304 response seems expected, as most servers use that to indicate the cached data is still good. From Microsoft's MDN documentation:

The server compares the client's ETag (sent with If-None-Match) with the ETag for its current version of the resource, and if both values match (that is, the resource has not changed), the server sends back a 304 Not Modified status, without a body, which tells the client that the cached version of the response is still good to use (fresh).

Alamofire doesn't do anything here, it's all handled by URLSession under the hood.

Upvotes: 0

Related Questions