when the client specifies the request Cache-control to be public and the server sets the response Cache-control to be public, then the Cache will still use the Cookie in the Vary header as its policy for determining whether the Cache is valid.Is this true?
In addition, okhttp still saves the response data when neither the request nor the response has the Cache-Control header set.
This problem is avoided by modifying the Vary header on the server side and removing the Cookie option when Cache-Control sets public
Related
I have JMeter test where after one request in response headers is set cookie with Max-Age property.
In following requests I am sending cookie in request body.
After Max-Age time pass I expect that jmeter stops sending cookie in request body. But it stil sends cookie.
I am using HTTP Cookie Manager with Cookie policy: standard-strict
Am I using HTTP Cookie Manager right?
How Cookie Manager handles Max-Age parameter in set-cookie in response header?
HTTP Cookie Manager doesn't send anything in the request body, it automatically parses incoming cookies and generates appropriate Cookie header
Looking into JMeter source code STANDARD_STRICT policy stands for RFC6265CookieSpecProvider with STRICT compatibility level
In its turn RFC6265CookieSpecProvider in STRICT mode invokes BasicMaxAgeHandler
So given you have HttpClient4 implementation of your HTTP Request sampler(s) (or even better in HTTP Request Defaults) the Max-Age check functionality should work (unless there is a bug in the HTTPClient itself)
I listed all cookies with preprocessor and cookie has set expires property to 12:43:12 and current time is 12:45:35 (current time is in milliseconds) ... so it seems that cookie with expires property does not work
PreProcessor: Cookie n° 2: sticky_fo: http://10.64.128.238:30701 expires: 1611146592 Current time: 1611146735233
I am trying to determine when newly set cache-control headers will be read by end-users who have previously cached a page.
Let's say a user loads a page that does not have any cache-control headers set. Then I add cache-control: no-cache, no-store header at the server level. Will it force even the users who had previously visited and cached the page to get the latest version? Or would their current version have to expire per their browsers rules since no headers were initially set?
The latter. Headers aren't pushed unless a user agent requests a resource. However, see this question. If a client makes a conditional request to validate its cache, those headers will also be sent in 304 responses. The spec says the cache MUST
use other header fields provided in the 304 (Not Modified)
response to replace all instances of the corresponding header
fields in the stored response.
How can a CDN cache the content of an HTTPS request using the Cache-Control Header if the headers of the response are all encrypted?
Does the CDN have to be given explicit permission to decrypt the payload and then reencrypt it?
In that case what is the purpose of the public/private values for the Cache-Control header? (In the case where you have to explicitly give the CDN access to the encrypted payloads?
CDN acts like a reverse proxy with cache capability. Every connection is initialized and terminated at CDN POP. If no corresponding items found in the cache, another connection to origin is issued to fetch the data and determine whether to cache it according to the cache policies CDN user defined.
As far as HTTPS concerned, data is decrypted and reencrypted, you need to deploy your SSL certificate to your CDN provider. All the response from origin are visible to CDN.
The value of "Cache-Control" is used as a hint for CDN provider to determine whether they need to cache the item or not.
Cache-Control: private indicates that all or part of the response
message is intended for a single user and MUST NOT be cached by a
shared cache, such as a proxy server.
From RFC2616 section 14.9.1
CDN providers usually do not cache response with cache-control header set to private but you can override the behavior with your own rules. Almost every CDN provider allows you to customize cache policies.
What'll happen if I set server response as:
Cache-Control: private,no-cache,max-age=900?
What'll happen if the header is like:
Cache-Control: public,no-cache,max-age=900?
Since it has a no-cache whether browser (Or proxy server) consider the max-age?
As stated in the RFC documents:
If the no-cache directive does not specify a field-name, then a cache
MUST NOT use the response to satisfy a subsequent request without
successful revalidation with the origin server. This allows an origin
server to prevent caching even by caches that have been configured to
return stale responses to client requests.
As a result, if no-cache has been defined in a server's response, this means that the browser (and any intermediary caches) will "revalidate" on every request (aka make a request to the origin server and return its response, instead of using any cached content).
So, to clearly answer your question:
Since it has a no-cache whether browser (Or proxy server) consider the
max-age?
No, the browser will not consider the max-age (given that the browser can handle the no-cache directive, since this might not recognized by some HTTP 1.0 browsers/caches).
When Authorization header present in the inbound request, it's always a Cache Miss. My requirement is, I need ATS to treat the Authorization header like any other header (It should not cause cache miss and it should get forwarded to upstream service). How can I achieve this.
This may sound non-secure, but, I have a specific usecase for this. This cache is for internal use and it's access is controlled by other means.
I tried this
As per the official documentation
By default, Traffic Server does not cache objects with the following
request headers:
Authorization
Cache-Control: no-store
Cache-Control: no-cache
To configure Traffic Server to ignore this request header,
Edit proxy.config.http.cache.ignore_client_no_cache in records.config.
CONFIG proxy.config.http.cache.ignore_client_no_cache INT 1 Run the
command traffic_ctl config reload to apply the configuration changes.
but, no luck
If your origin returns a cache-control header with the 'public' directive (for instance, "Cache-Control: max-age=60,public") or including the s-maxage directive (for instance, "Cache-Control: s-maxage=60"), ATS should start caching the object. The relevant http RFC:
https://www.rfc-editor.org/rfc/rfc2616#section-14.8
When a shared cache (see section 13.7) receives a request
containing an Authorization field, it MUST NOT return the
corresponding response as a reply to any other request, unless one
of the following specific exceptions holds:
1. If the response includes the "s-maxage" cache-control
directive, the cache MAY use that response
...
3. If the response includes the "public" cache-control directive,
it MAY be returned in reply to any subsequent request.
Similarly, you could also use the header_rewrite plugin to remove the Authorization header from the request, or to add public/s-maxage.
Actually this https://docs.trafficserver.apache.org/en/latest/admin-guide/configuration/cache-basics.en.html#configuring-traffic-server-to-ignore-www-authenticate-headers did the trick for me.
The following instructions was applicable for Authorization header as well, besides WWW-Authenticate Header. They need to update the documentation.
Configuring Traffic Server to Ignore WWW-Authenticate Headers
By default, Traffic Server does not cache objects that contain WWW-Authenticate response headers. The WWW-Authenticate header contains authentication parameters the client uses when preparing the authentication challenge response to an origin server.
When you configure Traffic Server to ignore origin server WWW-Authenticate headers, all objects with WWW-Authenticate headers are stored in the cache for future requests. However, the default behavior of not caching objects with WWW-Authenticate headers is appropriate in most cases. Only configure Traffic Server to ignore server WWW-Authenticate headers if you are knowledgeable about HTTP 1.1.
To configure Traffic Server to ignore server WWW-Authenticate headers:
Edit proxy.config.http.cache.ignore_authentication in records.config.
CONFIG proxy.config.http.cache.ignore_authentication INT 1
Run the command traffic_ctl config reload to apply the configuration changes.