Sorry about the bad quoting, somehow the message evaded my email client.
Paul Davis wrote:
I'm not really concerned with major user agents in terms of headers we add. Most of those should be configured to do the right thing 99% of the time regardless. The question is what would I do if I tried implementing a client? Setting all of these caching headers may fix popular browsers, but for those that want to speak raw HTTP it just complicates the crap out of everything.
IE 6 can be reconfigured to use a different heuristic to determine whether a doc is stale and needs to be revalidated when there is not an explicit Expires or max_age. IE 6's default behavior is documented (link in the bug report) and as far as I can tell is not invalid. I don't see any explicit statement in the spec on what a client should assume for an expiry date when one is not provided by the server. MS just decided something different than the other implementers. It is not a desirable thing to try to convince a client that they need to change some advanced setting to get your app to work.
I do not see how providing a nearly universal HTTP 1.0 Header in the response would in anyway complicate any thing for someone writing their own HTTP stack. It seems highly unlikely that any significant HTTP stack would be impacted by the addition of an explicit Expires header instead of the current reliance on an implied expiration.
Just to be clear, its forbidden by the spec, but breaking compliance to fix IE6 is something that should be considered.
What specifically are you saying is forbidden by the spec? The preceding paragraph is talking about "Cache-Control: max-age=0" which I can't make any case for reading as forbidden by the spec. It reduces the incidences of stale data, but still leaves a 1 second window at least in the browsers I've tested.
> I'm convinced on custom headers.
I'm not sure how to interpret that statement. I'd like to interpret as an willingness to consider for configurable headers.
