search

jshttp / fresh

HTTP request freshness testing
MIT License
161 stars 28 forks source link

Why check cache-control: no-cache? #16

Closed abbr closed 7 years ago

abbr commented 9 years ago

Hi, If a request contains both header cache-control: no-cache and a fresh etag, fresh will mark the request not fresh. I don't understand why. According to w3.org's explanation about no-cache: 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 directive only tells a proxy to revalidate with the server. It shouldn't be used by origin server to determine a cached content is stale, which is the job of etag and last modified timestamp header.

I encountered this problem when using IE XDomainRequest. IE added cache-control: no-cache automatically if previous response has header Cache-Control: max-age=0 and there is no way to disable the request header.

dougwilson commented 9 years ago

Hi!

I'm sorry you're experiencing an odd browser behavior, but this module is acting exactly according to specification. So I think you may be confused on this: there is a Cache-Control response header and there is also a Cache-Contol request header. The Cache-Control this module is looking at is the request header, not the response header. The link you provided only refers to the response header, as you can see in the link, it says:

The following Cache-Control response directives [...]

As you can see, they are telling you they are talking about the Cache-Control response header.

When Cache-Control: no-cache is part of the request, we cannot send back a cached response and must teat tit as always stale. This Stackoverflow answer will also help understand about how request vs response headers have different meanings: https://stackoverflow.com/questions/1046966/whats-the-difference-between-cache-control-max-age-0-and-no-cache#answer-1383359

dougwilson commented 9 years ago

I'm going to re-open this for greater re-evaluation, since this change was added before this module came into jshttp. I also need to know exactly how Apache and nginx act as well.

dougwilson commented 9 years ago

The point at which this behavior was introduced into this module was pull request #2 and it's actual premise was not the greatest: "I want a way to tell Express to ignore caching"

abbr commented 9 years ago

The explanation is not specific to response header, as indicated in sec 14.9

dougwilson commented 9 years ago

Sorry, I'm not 100% sure what you mean; your original link was to section 14.9.1, not 14.9. 14.9.1 states it's only talking about response headers, which I quoted above.

Regardless, the PR that added this behavior has dubious standing to me, and it does seem clear that only caches should be looking at this header, rather than the origin server. But I need to know the exact behavior of Apache and nginx in regards to this before acting, as I want to make sure we're in line with the Internet as a whole.

dougwilson commented 9 years ago

Basically what I'm saying is that I need to be absolutely sure that this is the correct change before making it, since it has existed so long. Just accepting things without doing research first is exactly how this behavior ended up within the mode in the first place :)

I need to determine the following things:

  1. How does Apache behave
  2. How does nginx behave
  3. Determine the spec this is (RFC 2616 has been superseded, by the way, so I need a reference from the current HTTP/1.1 specs)
abbr commented 9 years ago

Hi Doug, what I mean is the grammar syntax given in sec 14.9 references explanation in 14.9.1 regardless of request or response.

dougwilson commented 9 years ago

Hi Doug, what I mean is the grammar syntax given in sec 14.9 references explanation in 14.9.1 regardless of request or response.

Ah, yes. This is because the syntax of the Cache-Control header is the same for both request and response headers. What is different between the request and response is the behavior is all. This issue is about the behavior :)

alexandrethsilva commented 9 years ago

Hi @dougwilson, I believe this issue is directly related to Safari's blank pages when sending a Cache-Control: max-age=0, no? Do you have any news on this? I currently have the fix on my local version, but it's of course the worst possible solution and it would be nice to know that I can just have a correct synced version with the repo.

For what I understood from the spec you guys are mentioning, Safari is not behaving wrongly... So I wonder what's the possible solution if not here.

dougwilson commented 9 years ago

So I wonder what's the possible solution if not here.

The issue is a bug in Safari. The reason it ends up with a blank page is due to a race condition within it's own client-side caching mechanism. I believe this may be fixed in the very latest versions of Safari, but I do not know. There is nothing we can do here to help Safari overcome it's bug without user-agent sniffing, which we will not do.

Your best solution is to use the https://github.com/Dakuan/jumanji module.