New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 635350 link

Starred by 2 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

If link prefetching returns 404, PUT to the same URL returns cached 404

Reported by d.huig...@gmail.com, Aug 7 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/51.0.2704.79 Chrome/51.0.2704.79 Safari/537.36

Example URL:

Steps to reproduce the problem:
You can reproduce on any website, although it is of course only a problem if GET /test returns 404 while PUT /test wouldn't necessarily also return a 404. Open the Network tab and run the following code. Observe that the second request says (from cache). It's not lying, the PUT request isn't made.

    var url = '/test'; // Nonexistent location. If it exists it works fine
    var link = document.createElement('link');
    link.rel = 'prefetch';
    link.href = url;
    document.body.appendChild(link);
    setTimeout(function() {
        var req = new XMLHttpRequest();
        req.open('PUT', url); // POST works fine
        req.send('test'); // Without a body it works fine
    }, 500);

What is the expected behavior?

What went wrong?
I'm not sure, but I believe a cached 404 from GET /test shouldn't be returned for PUT /test.

Did this work before? N/A 

Chrome version: 51.0.2704.79  Channel: n/a
OS Version: 
Flash Version: Shockwave Flash 11.2 r999
 
Cc: ranjitkan@chromium.org
Labels: M-54 OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on Windows 7, MAC 10.11.5, Ubuntu 14.04. for chrome stable version 52.0.2743.116. Attached screen shot for the same. Issue is seen from M24 - 240.1300.0. Untriaging it so that it gets addressed.

P.S: issue is not seen on FF browser.

Thanks.!
Screen Shot 2016-08-08 at 1.13.19 PM.png
117 KB View Download
Components: -Internals>Network Internals>Network>Cache
Cc: gavinp@chromium.org
I can repro on 52 stable, but looks like it's been fixed in 53 beta.  Can confirm it looks to be an issue at net's cache layer, and not blink's in-memory cache.
Should this be marked fixed due to #3?

Sign in to add a comment