You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
/* "1. To inform cache recipients that they MUST NOT use this response
to satisfy a later request unless the later request has the same
values for the listed fields as the original request (Section 4.1
of [RFC7234]). In other words, Vary expands the cache key
required to match a new request to the stored cache entry."
If we do not store this response, we will never use it to satisfy a later request, including a later request for which it would be incorrect.
*/
if httpResponse.allHeaderFields["Vary"]!=nil{
return false
}
A use case here might be Vary: Accept-Language to allow responses for different languages to be cached separately so if a user changes languages in a mobile-App for example, a response in the wrong language wouldn't be returned to them / the right response would be returned to them if it had been cached for the cache keys derived from the header...
The text was updated successfully, but these errors were encountered:
aodhol
changed the title
RFC conformance
RFC7234#section-7.1.4 conformance
Nov 26, 2023
The implementation returns nil upon seeing the
Vary
header but is that what the standard implies? Shouldn't the cache keys be expanded instead?swift-corelibs-foundation/Sources/FoundationNetworking/URLSession/HTTP/HTTPURLProtocol.swift
Lines 215 to 226 in 36a411b
A use case here might be
Vary: Accept-Language
to allow responses for different languages to be cached separately so if a user changes languages in a mobile-App for example, a response in the wrong language wouldn't be returned to them / the right response would be returned to them if it had been cached for the cache keys derived from the header...The text was updated successfully, but these errors were encountered: