Issue 68298 in chromium: HTTP Error 416 Requested Range caused by Chrome
chro...@googlecode.com
Owner: ----
Labels: Type-Bug Pri-2 Area-Undefined
New issue 68298 by gdevise: HTTP Error 416 Requested Range caused by Chrome
http://code.google.com/p/chromium/issues/detail?id=68298
Chrome Version : 8.0.552.224
URLs (if applicable) : none
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5: OK
Firefox 3.x: OK
IE 7/8: OK
What steps will reproduce the problem?
I manage a huge Apache/PHP website and in I notice that a lot of "HTTP
Error 416 Requested Range not satisfiable" are generated by only one
browser : Chrome in its last version.
It seems to only impact images (.PNG).
No step identified... I can't reproduce it... There are about 10 errors a
day on 1000 visitors.
What is the expected result?
No HTTP error like the others browsers
What happens instead?
HTTP Error 416
chro...@googlecode.com
Owner: rvar...@chromium.org
Labels: -Area-Undefined Area-Internals Internals-Network
Comment #1 on issue 68298 by will...@chromium.org: HTTP Error 416
Requested Range caused by Chrome
http://code.google.com/p/chromium/issues/detail?id=68298
(No comment was entered for this change.)
chro...@googlecode.com
Comment #6 on issue 68298 by rva...@chromium.org: HTTP Error 416 Requested
http://code.google.com/p/chromium/issues/detail?id=68298
That's the version of our current stable release... so most of our users
are there.
I think we use byte-range requests more than other browsers, and this could
be caused by a bug on our end. But it also can be a problem with the
server :(
chro...@googlecode.com
Comment #7 on issue 68298 by downch...@gmail.com: HTTP Error 416 Requested
http://code.google.com/p/chromium/issues/detail?id=68298
I'm getting the same issue on nginx using Chrome 11.0.657.0 with
application cache. By request ~55, it crashes out. It's hard to debug on
Chrome side, as app-cache requests don't show up in the resource log. nginx
is showing it as a 416 in the access log.
chro...@googlecode.com
Comment #9 on issue 68298 by kiddai...@gmail.com: HTTP Error 416 Requested
http://code.google.com/p/chromium/issues/detail?id=68298
Just thought I'd chime in on this since I stumbled upon this issue while
trying to figure out the resolution.
One of my servers running Windows Server 2008/IIS7 is occasionally/randomly
reporting 416 errors when serving images to Chrome browsers. These are all
simple GET requests for image URLs, and in my case, all JPGs. It doesn't
happen with any other file type or with any other browser.
Going back through my logs, I specifically see the error happening with
Chrome versions: Chrome/9.0.597.98, Chrome/9.0.597.94, Chrome/9.0.597.84
and Chrome/8.0.552.237.
Some other things I've noticed that may or may not have anything to do with
it:
* All of the HTTP_ACCEPT_LANGUAGE headers are non-English as the first
language, ie. "ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4" and "es-419,es;q=0.8"
* All of the requests that this has happened on appear to be originating
from outside the US. The server itself is in Texas.
Unfortunately, I haven't been able to reproduce this myself on the browser
side (I'm running Chrome/9.0.597.98), so I can only report what I'm seeing
from the server.
chro...@googlecode.com
Comment #10 on issue 68298 by pellaea: HTTP Error 416 Requested Range
http://code.google.com/p/chromium/issues/detail?id=68298
Two more cents worth: mushroomobserver.org was sending 416s to a user who
uses Chrome. We, too, had trouble tracking it down because the same
request from the same URL won't reliably reproduce it from the browser
side. I seem to have solved it on the server side by
adding "Accept-Ranges: none" to our response headers. (Using apache
mod_headers: add "Header set Accept-Ranges none" to conf file.) (fingers
crossed)
We have dynamic content, so is it possible chrome expects same length for
identical requests and is explicitly asking for same length it received
last time? It might work fine if new response > old response, but not if
new < old. It would possibly explain apparent randomness for identical
requests. Pure speculation...
chro...@googlecode.com
Status: Assigned
Labels: Mstone-13
Comment #13 on issue 68298 by rva...@chromium.org: HTTP Error 416
Requested Range caused by Chrome
http://code.google.com/p/chromium/issues/detail?id=68298
Thanks for the log.
For the most part it looks like a problem with the servers, as it should
not return 416 for a resource with a different etag.
However, there is a small bug with the second request because it looks like
it is trying to resume a truncated request that actually completed. That
should not be common, but I see how that can happen.
chro...@googlecode.com
Comment #14 on issue 68298 by justin.g...@gmail.com: HTTP Error 416
http://code.google.com/p/chromium/issues/detail?id=68298
I suspect it's returning 416 because the resource with the new etag
(2697630952) is smaller than the original resource. I do not see any
problem with the servers other than their desynched clocks.
Okay, so you think there's a bug causing chrome to think the cached content
was truncated, when it wasn't. That doesn't address chromium's combining
If-None-Match: and Range: headers.
Suppose there was a request that was really truncated, and chrome correctly
cached partial content. In that case chrome will send the same kind of
request, right? Three possibilities:
(a) if the server is still serving the partially cached version of the
resource, the server will return 304 not modified. This is dictated by the
semantics of the If-None-Match: header (rfc2616 14.26)
(b) if the server is serving a new version of the resource, and the new
version is >= in size to the old version, the server will return the
requested range of the new version, corrupting the resource in chrome's
cache if chromium combines the new partial content with the old cached
partial content. If chromium doesn't accept the new content, then the
request was wasted.
(c) if the server is serving a new version of the resource, and the new
version is smaller than the old version, the server returns 416 because the
byte range is not satisfiable.
In any of those cases the result of the request will not help Chrome
complete its cached, truncated version of the resource. I think it should
be using If-Match: instead of If-None-Match:, or else it should not be
trying ranged requests to complete partial cached content.
chro...@googlecode.com
Comment #15 on issue 68298 by rva...@chromium.org: HTTP Error 416
http://code.google.com/p/chromium/issues/detail?id=68298
Almost...
Combining If-none-match with the range headers is also the result of the
same bug... we don't do that intentionally.
But yes, given the headers that we send, the server seems to be right (as
in 416 was expected, but in this case, even switching etag is ok).
chro...@googlecode.com
Comment #17 on issue 68298 by rva...@chromium.org: HTTP Error 416
http://code.google.com/p/chromium/issues/detail?id=68298
re comment 16: I don't see any info on that forum that links that issue
with this bug. Are you sure you meant to comment on this bug?
chro...@googlecode.com
Comment #19 on issue 68298 by rva...@chromium.org: HTTP Error 416
http://code.google.com/p/chromium/issues/detail?id=68298
Ok, I see the link.
That's interesting but I'd be surprised if this is the cause of their
problem: I stand by my opinion that the case that we don't handle correctly
is when we read all data from the network but we did not perform one last
read (that returns 0 bytes) and then we cancel the load (marking the
resource as being truncated).
I changed the way that we validate truncated resources with the server for
version 11, but I see no other bug with the new code (and it's better for
servers that lack full support for byte ranges).
In any case, this should be fixed soon so we'll see.
chro...@googlecode.com
Comment #22 on issue 68298 by brendon....@gmail.com: HTTP Error 416
http://code.google.com/p/chromium/issues/detail?id=68298
I think this is fairly urgent. The longer this bug is out in the wild, the
more users' cache will get affected by this bug. I'm seeing now on quite a
few Rails+Passenger web sites.
chro...@googlecode.com
Comment #27 on issue 68298 by findPras...@gmail.com: HTTP Error 416
http://code.google.com/p/chromium/issues/detail?id=68298
This issues happens to our website also. Our weblogs indicate increasing
frequency of this response code.
This is a very severe issue, as the JS, CSS resources have expires headers
set far in the future (in keeping with the best practices guidelines. The
only workaround is to clear browser's cache, apart from adding code to
strip out this header on the server side.
chro...@googlecode.com
Comment #28 on issue 68298 by jkkra...@gmail.com: HTTP Error 416 Requested
http://code.google.com/p/chromium/issues/detail?id=68298
I'm seeing this bug regularly on one of my sites. It seems to be fixed in
the latest nightly. This is the only time I've ever been grateful that most
of my users run IE.
chro...@googlecode.com
Comment #29 on issue 68298 by kella...@gmail.com: HTTP Error 416 Requested
http://code.google.com/p/chromium/issues/detail?id=68298
As a user, I got this error in the popup when trying to login in to net
banking on http://www.stgeorge.com.au
I'm using google chrome 12.0.742.112 on ubuntu 11.04 (64 bit).
Switched over to firefox 5.0 and it worked fine.
chro...@googlecode.com
Comment #30 on issue 68298 by ntor...@gmail.com: HTTP Error 416 Requested
http://code.google.com/p/chromium/issues/detail?id=68298
Seeing this on Mac Chrome 12.0.742.112. Looking in the Chrome cache I see
these response headers:
HTTP/1.1 200 OK
Date: Thu, 07 Jul 2011 06:59:46 GMT
Server: Apache
Last-Modified: Fri, 01 Jul 2011 03:18:50 GMT
ETag: "11c38a-9e7-4a6f979f4da80"
Accept-Ranges: bytes
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 1063
Content-Type: text/html; charset=UTF-8
Chrome is launching this request:
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
If-None-Match:"11c38a-9e7-4a6f979f4da80"
Range:bytes=1063-1063
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_4)
AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.112 Safari/534.30
Which doesn't work (gets a 416) as byte ranges are 0-based and this file
has only 1063 bytes.
chro...@googlecode.com
Comment #31 on issue 68298 by rva...@chromium.org: HTTP Error 416
http://code.google.com/p/chromium/issues/detail?id=68298
ntor...@gmail.com: see comment 26
chro...@googlecode.com
Comment #32 on issue 68298 by ntor...@gmail.com: HTTP Error 416 Requested
http://code.google.com/p/chromium/issues/detail?id=68298
Confirmed I cannot reproduce the problem in the beta build.
chro...@googlecode.com
Comment #33 on issue 68298 by colinod...@gmail.com: HTTP Error 416
http://code.google.com/p/chromium/issues/detail?id=68298
I just had this issue occur today in Chrome 12.0.742.112. An AJAX call to
load an HTML page resulted in a "Range" header similar to the one in
Comment #30 (the numbers are different, but its definitely
Range:bytes=xxxx-xxxx).
I have been unable to determine how to replicate it, but clearing the cache
causes it to work again. Today when I loaded the same page with
13.0.782.41 beta-m, the issue did not occur and after multiple attempts the
issue has not been reproduced.
However, on June 14th, the error _did_ occur in the beta build I was using
at that time, but I did not record the version number when it happened. I
keep my tabs open for days, so it's possible I was using a v12 release then.