<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Safari fails to clear ETag cache after 404"
href="https://bugs.webkit.org/show_bug.cgi?id=156048">156048</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Safari fails to clear ETag cache after 404
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>Product</th>
<td>WebKit
</td>
</tr>
<tr>
<th>Version</th>
<td>WebKit Nightly Build
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Macintosh
</td>
</tr>
<tr>
<th>OS</th>
<td>OS X 10.11
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>Normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P2
</td>
</tr>
<tr>
<th>Component</th>
<td>Page Loading
</td>
</tr>
<tr>
<th>Assignee</th>
<td>webkit-unassigned@lists.webkit.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>nolan@nolanlawson.com
</td>
</tr>
<tr>
<th>CC</th>
<td>beidson@apple.com
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=275241" name="attach_275241" title="Reproducible test case">attachment 275241</a> <a href="attachment.cgi?id=275241&action=edit" title="Reproducible test case">[details]</a></span>
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: <a href="https://gist.github.com/nolanlawson/6cc2a537d390578bc235c00996f5b938">https://gist.github.com/nolanlawson/6cc2a537d390578bc235c00996f5b938</a>. Steps to reproduce are in the _readme.md.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>