[Webkit-unassigned] [Bug 72414] New: Entity-header extension headers honored on 304 responses.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=72414

           Summary: Entity-header extension headers honored on 304
                    responses.
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: tsepez at chromium.org
                CC: abarth at webkit.org


RFC2616 10.3.5 says that headers returned by a 304 Not Modified response should update the fields from the original response.  But there are a class of entity headers which should not be sent by servers when generating a 304 response.  If they should be sent, browsers have adopted a policy of ignoring them and using the field values from the original non-cached request instead.  

FRC2616 7.1 calls out extension headers to be entity headers.  While it is a stretch to imagine that all of these are such, the following describe entities:

X-Content-* headers
X-WebKit-CSP since it is a placeholder for X-Content-Security-Policy
X-XSS-Protection

We've run into at least one proxy that adds an X-Content-Type-Options to its 304 requests that was not present in the orignal response, which is what has prompted thinking about the general problem.  In particular, it would be bad if a 304 response turned off protections set by headers on the original uncached request.

I've got a couple of test cases for X-WebKit-CSP and X-XSS-Protection that I will be adding shortly.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.