Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 80 users
Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Aug 2012
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment
HTTP DELETE request loaded from Cache
Reported by sebastia...@gmail.com, Jul 9 2012 Back to list
Chrome Version: 20.0.1132.47
OS Version: OS X 10.7.4

Other browsers tested:
* Safari 5.1.7: OK
* Firefox 13.0.1: OK

What steps will reproduce the problem?

1. Given a REST service, request a resource with caching headers. e.g.:

Request URL: http://localhost:8888/files/cat.jpg
Request Method: GET
Status Code: 200 OK

Response Headers
Cache-Control:max-age=3600

2. Next send a HTTP DELETE request for the same resource

Request URL:http://localhost:8888/files/cat.jpg
Request Method:DELETE
Status Code:200 OK (from cache)


What is the expected result?

Chrome should issue a DELETE request for the given resource, ignoring any cache contents.

From the spec for HTTP 1.1 (RFC 2616) Section 9.7 DELETE:

   If the request passes through a cache and the Request-URI identifies
   one or more currently cached entities, those entries SHOULD be
   treated as stale. Responses to this method are not cacheable.


What happens instead?

Chrome loads the contents for the given resource from disk.


Please provide any additional information below. Attach a screenshot if
possible.

The REST service used in the tests above was located on a different domain, so cross-domain OPTIONS requests were issued before the DELETE requests. I'm not sure if this has anything to do with the caching behavior.


UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11


The following issue may be related, though it's marked as fixed:
http://code.google.com/p/chromium/issues/detail?id=112968

 
Labels: -Area-Undefined Area-Internals Internals-Network-Cache
Comment 2 by zgstew...@gmail.com, Jul 11 2012
I'm experiencing this issue as well on version 20.0.1132.47

> Request URL:http://localhost:3000/products/33/segments/1974/charts/1460
> Request Method:GET
> Status Code:200 OK

< Cache-Control:max-age=31536000, private, must-revalidate
< Date:Wed, 11 Jul 2012 18:53:24 GMT

>Request URL:http://localhost:3000/products/33/segments/1974/charts/1460
> Request Method:DELETE
> Status Code:200 OK (from cache)
Comment 3 Deleted
Comment 4 Deleted
Comment 5 Deleted
Comment 6 Deleted
Comment 7 Deleted
Comment 8 Deleted
Labels: -Pri-1 -Restrict-AddIssueComment-Commit Pri-2
I'm not able to repro... and the code looks fine to me.

Please follow the instructions of
http://www.chromium.org/for-testers/providing-network-details

and attach a network log.
Can I send this to you privately? although it has a "strip private information" there, there is information there I can't publicly share, and will take me a lot of time to strip it down?
Yes, feel free to email it to me.
  some people prefer privacy
Comment 13 by caj...@gmail.com, Jul 31 2012
Personally to me it looks like not very well configured web server too (along with strange behavior of Chromium). If it supposed that some file may disappear sooner or later you'd better add "must-revalidate" to Cache-Control header.
I've attached a network log.
It has been captured by using the sample Node.js server of the jQuery File Upload project:
https://github.com/blueimp/jQuery-File-Upload

You can reproduce it yourself by
1. Downloading the project repository.
2. Running the Node.js sample server.
3. Adjusting the form action in index.html to the Node.js server URL (http://localhost:8888 by default).
4. Accessing the index.html via your local webserver (e.g. Apache).
5. Uploading a file (e.g. cat.jpg).
6. Accessing the uploaded file.
7. Trying to delete the uploaded file (which will result in Chrome returning the cached file).
net-internals-log.json
52.0 KB View Download
thank you for the quick reply
Labels: -OS-Mac
Owner: rvargas@chromium.org
Status: Started
Now I see the bug in the revalidation logic.
Comment 17 by an...@xola.com, Aug 1 2012
Would this bug cause a similar issue with PUT requests? I'm facing an identical issue where Chrome responds from cache even though it was a HTTP PUT request. (screenshots attached)

Let me know if I should file a separate bug for that?
chrome-put-header.png
32.0 KB View Download
chrome-put-cache.png
29.1 KB View Download
This is a similar problem to the symptom(s) described in bugs  79758  and  94369 . It might be worthwhile to investigate whether there is a common cause.
re. comment 16: Yes, PUT goes through the same logic. The fix covers both.

re. comment 17: No, please don't mud the waters.
Project Member Comment 20 by bugdroid1@chromium.org, Aug 2 2012
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=149643

------------------------------------------------------------------------
r149643 | rvargas@google.com | 2012-08-02T17:13:04.047924Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_cache_unittest.cc?r1=149643&r2=149642&pathrev=149643
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_cache_transaction.cc?r1=149643&r2=149642&pathrev=149643

Http cache: Always revalidate PUT and DELETE requests.

BUG= 136320 
TEST=net_unittests
Review URL: https://chromiumcodereview.appspot.com/10829114
------------------------------------------------------------------------
Status: Fixed
The fix is on the canary build (https://tools.google.com/dlpage/chromesxs/) and should reach the dev channel next week.
Labels: Mstone-21 Merge-Requested
Comment 23 by ddrew@chromium.org, Aug 23 2012
Labels: OS-All
Comment 24 by kareng@google.com, Aug 24 2012
was this on m22 too?
The fix landed before M22 branch.
Comment 26 by Deleted ...@, Aug 24 2012
Does the fix cover DELETE, PUT and POST? Also are the Location and Content-Location response headers being used to invalidate cached resources now too? If not it's still broken.
POST is not related to this bug.

There's no content-location driven actions taken by the cache. Please file a new report for that.
Comment 28 by kareng@google.com, Sep 24 2012
Labels: Merge-Rejected
well past m21 now.
Comment 29 by kareng@google.com, Sep 24 2012
Labels: -Merge-Requested
Comment 30 Deleted
Comment 31 by Deleted ...@, Oct 15 2012

Dear Friends,

I'm stuck with blurring issue for secondary svg image inside primary svg response on every ajax call in google chrome browser 

only.

- On ajax call,i'm getting svg content as ajax response 
- Inside that response i have primary svg image that contains svg image tag with 

xlink:href(source) presenting secondary svg image file.
- I'm trying to  append that svg response to html division tag.But this secondary svg 

image is displayed blurred with Google Chrome Browser only.

I referred this link,http://code.google.com/p/chromium/issues/detail?id=119693 and 

googling over this topic,But search result ends up only with Google chrome cache issue with svg content

I tried removing this cache issue by 

appending a random string as a parameter behind secondary svg image source path/location.Now it gives a fresh response without blurring 

secondary svg image but it introduces issue of flashing/blinking of secondary svg image on each ajax call.

Please suggest the possible ways to 

get rid of this flashing issue in chrome browser.

Regards,
Shakti
Project Member Comment 32 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-Internals -Internals-Network-Cache -Mstone-21 M-21 Cr-Internals Cr-Internals-Network-Cache
Sign in to add a comment