Headers like 'content-type' should be ignored for 304 responses, even if they are delivered as 'Content-Type', or 'CoNtEnT-TyPe', etc. I broke this behavior in http://trac.webkit.org/changeset/142068 ("Entity-header extension headers honored on 304 responses"). This causes pages like https://learndev.unm.edu/ to break on reload, as they incorrectly send 'Content-Type: text/plain' for 304 responses for resources like CSS and JavaScript. https://code.google.com/p/chromium/issues/detail?id=246875 documents the Blink-side fix. I'll upload a patch shortly to fix the issue in WebKit.
Created attachment 210711 [details] Patch
Hi Alexey! Would you mind taking a look at this followup to the 7-month old http://trac.webkit.org/changeset/142068? Thanks!
Comment on attachment 210711 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=210711&action=review r=me Thank you, this is much appreciated. > LayoutTests/http/tests/cache/resources/stylesheet304-bad-content-type.php:7 > + header("HTTP/1.0 304 Not Modified"); I'd have used HTTP/1.1, because 1.0 should die, but this makes no difference in practice.
<rdar://problem/14929843>
Comment on attachment 210711 [details] Patch I'm still not sure how we get away with using WTF::Unicode::foldCase for HTTP headers everywhere, this should break with the letter "i" in Turkish locale. But this should not block landing.
Committed <http://trac.webkit.org/r155203>.
Can we add some test coverage for this?
My bad, I only committed WebCore by accident. Landed the test in r155208.