[Webkit-unassigned] [Bug 156048] New: Safari fails to clear ETag cache after 404

[bugzilla-daemon at webkit.org]

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

            Bug ID: 156048
           Summary: Safari fails to clear ETag cache after 404
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Macintosh
                OS: OS X 10.11
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: nolan at nolanlawson.com
                CC: beidson at apple.com

Created attachment 275241
  --> https://bugs.webkit.org/attachment.cgi?id=275241&action=review
Reproducible test case

This bug appears in WebKit Nightly (9.1 11601.5.17.1 r198834), but not the stable version of Safari (9.1 11601.5.17.1).

Steps to repro:

1. Safari performs a GET, server provides a cached response with an ETag
2. Safari requests with if-none-match and the server responds with a 304
3. Safari requests again, but resource has been removed so the server responds with a non-empty 404
4. Safari requests with if-none-match again, so server responds with 304 (this is where the bug occurs!)
5. Every subsequent request is a 304 for the *old* resource rather than the new resource

This is not a niche situation - it happens pretty frequently with CouchDB due to CouchDB re-using the revision identifier (_rev) as the ETag. If a resource is removed and re-created with the same _rev, then Safari will not ask for new content and will remain permanently stuck on old content.

If step 2 is skipped (i.e. Safari doesn't receive the 304 response), then the bug does not occur.

This bug cannot be reproduced in Firefox (which submits if-none-match) or Chrome (which doesn't submit if-none-match).

I've attached a test case as a ZIP file. I've also created a Gist: https://gist.github.com/nolanlawson/6cc2a537d390578bc235c00996f5b938. Steps to reproduce are in the _readme.md.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160331/d268800c/attachment.html>