@meaton Appreciate if you can confirm the behavior of URLCache is a bug or as expected. Thank you!

In some very rare cases it can happen with the URL, but typically the cached data is looked up based on URL, body data, or header data. The POST request with body should not be cached. I logged an issue (FB10141204) in the past and it is fixed in iOS 16. Is this a bug that request matching is not considering the header data/information?

Thanks for your reply @meaton! Yes, I see the same issue for POST requests as well. But why the caching is happening only based on the base URL? Shouldn't it consider the header informations too?

Thanks “The Eskimo!”!

The solution in my case was to create a new additional scheme only for authentication purpose e.g. "myappauth" Yes, that is the solution but in all cases its not possible to re-register scheme as we are accessing lot of customer portals. Would be grateful if someone from Apple address this. Regards, Nimesh

No, I haven't found any solution for this and logged a feedback with Apple.

Hi Matt,Sorry, but I'm not in control of the server to try changing anything server side.You can see in screenshots of the headers for request 1 and 2 - https://github.com/njarecha/URLCacheBug/blob/master/README.md, there are two additional headers `if-none-match` and `if-modified-since` for reqeust 2 which seems to be added based on cachePolicy by URLSession before sending request. The server is just honoring the provided headers and respond with status code `304`. So the question is why these headers are added to reqeust even though second request's HTTPbody is different than first request?Regards,Nimesh