etag to be put on the new auth request with the data from the old auth request, such that a 304 can result in not needing to update the cache
From http://www.w3.org/TR/2012/WD-XMLHttpRequest-20121206/
For 304 Not Modified responses that are a result of a user agent generated conditional request the
user agent must act as if the server gave a 200 OK response with the appropriate content.
The user agent must allow author request headers to override automatic cache validation
(e.g. If-None-Match or If-Modified-Since), in which case 304 Not Modified responses must be passed through. [HTTP]
I find this rather vague. My assumption would be if a resource is conditionally requested,
you would see the 304 response code. But, as I explained in another comment
(source: https://developers.google.com/speed/docs/best-practices/caching), there might not even
be a request if the last response server http header for that resource had set
Cache-Control: max-age or Expires set sometime in the future.
etag to be put on the new auth request with the data from the old auth request, such that a 304 can result in not needing to update the cache
From http://www.w3.org/TR/2012/WD-XMLHttpRequest-20121206/
For 304 Not Modified responses that are a result of a user agent generated conditional request the
user agent must act as if the server gave a 200 OK response with the appropriate content.
The user agent must allow author request headers to override automatic cache validation
(e.g. If-None-Match or If-Modified-Since), in which case 304 Not Modified responses must be passed through. [HTTP]
I find this rather vague. My assumption would be if a resource is conditionally requested,
you would see the 304 response code. But, as I explained in another comment
(source: https://developers.google.com/speed/docs/best-practices/caching), there might not even
be a request if the last response server http header for that resource had set
Cache-Control: max-age or Expires set sometime in the future.