implement support for 'Cache-control: no-cache="foo, bar"' : servers commonly send a 'Cache-control: no-cache="Set-Cookie"' header to instruct the web browser to not set the cookie again when reusing the cached data. in other words, the response data is typically cacheable, but mozilla currently only picks up the no-cache portion of the header and thinks the response should not be reused.

-> 0.9.9

mostly fixed with the landing of the patch for bug 112564. -> future

what else is missing here?

well, bug 112564 fixed the part about mozilla thinking that 'cache-control: no-cache="foo"' is equivalent to 'cache-control: no-cache', but mozilla still ignores 'cache-control: no-cache="foo"' i'm not sure that this bug actually effects any real world sites yet, but because this is part of the HTTP/1.1 standard, it might some day. targeting moz 1.4

-> suresh

moving to mozilla 1.4beta.

Discussed in topembed bug triage. Minusing.

This does affect real world sites (qv comment #4). See http://www.4guysfromrolla.com/webtech/111500-1.shtml for level of interest in stopping back key from trampling over transaction processing pages. What needs to be done to start this ball rolling?

> This does affect real world sites (qv comment #4). See > http://www.4guysfromrolla.com/webtech/111500-1.shtml for level of interest in > stopping back key from trampling over transaction processing pages. I don't think this bug is related. 'Cache-control: no-cache="foo"' tells the browser not to cache the "foo" response header. it doesn't say anything about the content of the page. 'Cache-control: no-cache' on the other hand says that the page contents cannot be re-used from the browser's cache without first validating the cached page contents with the server. NOTE: this does not apply to history mechanisms such as the Back and Forward buttons. If you are interested in making the browser not show your pages to users when they navigate Back or Forward to your page, then send the 'Cache-control: no-store' header with your pages.

Pre-emptively asking for wanted-1.9.2 and resetting milestone to get this bug properly triaged.

honza, is this something we should be doing or wontfixing? I can't say I've seen those response headers floating around - maybe the http archive would lend some light?

According [1] it's a "MAY" feature. And when I read the spec: "" If the no-cache response directive specifies one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, any header fields in the response that have the field-name(s) listed MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response. "" It seems like we won't save a round trip here anyway in most cases. If we treat no-cache="foo" as no-cache, we are probably OK (if I'm not mistaken.) Only benefit is when a header listed in no-cache is not present in the response. Then we can behave as no-cache has not been specified. According HTTP arch, there are 233433 from 47,719,497 (=0.5%) of requests having no-cache="foo" where foo is massively just "Set-Cookie" (2016_01_01_requests table). What do you think about that number? The implementation of this is probably not going to be that simple, benefit is going to be small if any, so I more tend to WONTFIXing this. [1] http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-26#section-5.2.2.2

Most current ref is: http://httpwg.github.io/specs/rfc7234.html#cache-response-directive.no-cache Treating no-cache="foo" as no-cache is just fine.