Over in bug 980006, we're fetching MDN pages using XMLHttpRequest. In bug 98006, comment 28, Luke suggested we should check that we are sending cache negotiation headers, so MDN can serve cached responses. It seems like we are sending the correct headers, but are not getting cached responses. In particular, we're sending If-None-Match, and it is matching the Etag in the response, but we're still getting a 200 response back, including an X-Cache-Info header "not cacheable; response had too large vary data", which might or might not mean something. Request headers: *** Host: developer.mozilla.org User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:39.0) Gecko/20100101 Firefox/39.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Cookie: <some cookies> Connection: keep-alive If-Modified-Since: Mon, 29 Dec 2014 02:40:55 GMT If-None-Match: "ecdb5e299137ffa7b910bd52aebaed3524276e90" *** Response headers: *** Access-Control-Allow-Credentials: false Access-Control-Allow-Methods: GET Access-Control-Allow-Origin: * Connection: Keep-Alive Content-Encoding: gzip Content-Type: text/html; charset=utf-8 Date: Wed, 11 Mar 2015 17:04:08 GMT Etag: "ecdb5e299137ffa7b910bd52aebaed3524276e90" Keep-Alive: timeout=5, max=992 Last-Modified: Mon, 29 Dec 2014 02:40:55 GMT Server: Apache Transfer-Encoding: chunked Vary: Cookie, Accept-Encoding X-Backend-Server: developer1.webapp.scl3.mozilla.com X-Cache-Info: not cacheable; response had too large vary data X-Robots-Tag: noindex X-kuma-revision: 713873 x-frame-options: Allow ***
:wbamberg, can you talk about the scale of this problem? The bug triage team thinks it may be a problem for devtools users; how many people or requests are affected by it? Is that going to grow dramatically soon?
I think from the devtools perspective we can leave this as minor. If Luke thinks it might give MDN problems server-side, we can look at it again.