Chunked Transfer causes Multiple Requests, the First Few of Which Terminate Prematurely
Reported by
man...@gmail.com,
Sep 22 2010
|
||||||||||
Issue description
Chrome Version : 6.0.472.63
Other browsers tested:
Safari 4: FAIL
Firefox 3.x: OK
What steps will reproduce the problem?
1. Setup a server that transmits and audio/ogg file via chunked transfer encoding
2. Access the file through Chrome.
3. Watch requests come in. More than one request for the file will be made. Chrome will terminate the connections to the server prematurely and then start a new connection. Eventually, it will work.
Here is some quick output of a very simple server I have written. The number in parentheses represents the number of bytes it's attempting to send. Note that I have truncated the full output, since this is a 1.5MB file being transmitted.
Note how the first request partially completes, the second request breaks after the first chunk, and the third requests works. I have chosen to send 16 bytes at a time for brevity's sake. I originally saw this problem when I was sending 16,384 byte chunks.
REQUEST: /audios/11/file.ogg
data(17): 'HTTP/1.1 200 OK\r\n'
data(31): 'Content-Type: application/ogg\r\n'
data(28): 'Transfer-Encoding: chunked\r\n'
data(37): 'Date: Wed, 22 Sep 2010 00:28:12 GMT\r\n'
data(2): '\r\n'
data(4): '10\r\n'
data(18): 'OggS\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\xbb/\r\n'
data(4): '10\r\n'
data(18): 'vT\x00\x00\x00\x00\\q\x88\xd5\x01\x1e\x01vor\r\n'
data(4): '10\r\n'
data(18): 'bis\x00\x00\x00\x00\x02D\xac\x00\x00\x00\x00\x00\x00\r\n'
... SEVERAL LINES LATER
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 60584)
Traceback (most recent call last):
...
error: [Errno 32] Broken pipe
----------------------------------------
REQUEST: /audios/11/file.ogg
data(17): 'HTTP/1.1 200 OK\r\n'
data(31): 'Content-Type: application/ogg\r\n'
data(28): 'Transfer-Encoding: chunked\r\n'
data(37): 'Date: Wed, 22 Sep 2010 00:28:13 GMT\r\n'
data(2): '\r\n'
data(4): '10\r\n'
data(18): 'OggS\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\xe7\x1b\r\n'
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 60585)
...
error: [Errno 32] Broken pipe
----------------------------------------
REQUEST: /audios/11/file.ogg
data(17): 'HTTP/1.1 200 OK\r\n'
data(31): 'Content-Type: application/ogg\r\n'
data(28): 'Transfer-Encoding: chunked\r\n'
data(37): 'Date: Wed, 22 Sep 2010 00:28:13 GMT\r\n'
data(2): '\r\n'
data(4): '10\r\n'
data(18): 'OggS\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00*d\r\n'
data(4): '10\r\n'
data(18): 'tT\x00\x00\x00\x00\x95Ta\x8b\x01\x1e\x01vor\r\n'
data(4): '10\r\n'
data(18): 'bis\x00\x00\x00\x00\x02D\xac\x00\x00\x00\x00\x00\x00\r\n'
... CONTINUES TO COMPLETION
,
Jan 20 2011
Assigning to acolwell since he's working on this area now.
,
Mar 4 2011
Possibly related to this (I wasn't sure so I logged another bug) is Issue 74975 . Please refer to it when fixing/resolving this Issue. Summary: ------- When the request for the audio stream results in a HTTP redirect (302/307), it is incorrect to hit the redirected URL a second time. If you *must* hit the URL again, Chrome should hit the original URL and then follow the redirect again.
,
Apr 1 2011
Additional comment: Firefox 3.x and Firefox 4 both don't make multiple requests for ogg resources.
,
Jul 20 2011
acolwell: any feedback/advice for this bug?
,
Aug 18 2011
,
Oct 24 2011
,
Nov 16 2011
No feedback received. Closing bug
,
Nov 16 2011
Is the bug fixed? I'm not sure what feedback/advice is being asked for.
,
Nov 16 2011
Sorry mankyd - miscommunication during triage (the Action-FeedbackNeeded label was asking for feedback from acolwell, not you). At any rate, I think this report is a dup of bug 82027 , with the twist that for ogg we have to fetch metadata from the end of the file. Do you agree?
,
Nov 16 2011
They do sound like dupes. I had 3 requests in my example as opposed to two requests, but I don't recall whether it was consistently three requests or not. As for whether fetching from the end of the of the file is necessary, I'll let you guys make the final call, but in the end, the browser is able to play the file without first reading the end, so it must not be _entirely_ necessary. Similarly, since the server responded with a chunked transfer and no indication that it supported range requests, I would think the browser could be intelligent enough to detect that it should simply start streaming the file.
,
Nov 17 2011
fischman: Like mankyd said, it would great to get Chrome to recognize servers which do not support range requests for ogg streams (and hence cannot seek to the end) - if you can a note about that to 82027, that would be great.
,
Nov 17 2011
The only way Chrome can detect that the server doesn't support range requests is to try a Range request and see what happens. The presence of a chunked response does not imply lack of Range support. I'll make a note in 82027.
,
Nov 17 2011
Thanks. Lack of the accepts-range response header is an indication that the server doesn't support it (and conversely, presence of the header indicates support). Currently, it looks like Chrome tries to make a range request even if the server doesn't exhibit support.
,
Nov 17 2011
This is true: chunked responses don't indicate lack of range support, but the Accept-Ranges header does. Perhaps that can be looked for: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.5
,
Nov 17 2011
Unless the server sends Accept-Ranges: none the client can't assume it doesn't support ranges. (the mere absence of Accept-Ranges is not sufficient, because Range-accepting servers aren't required to say Accept-Ranges: bytes)
,
Nov 17 2011
Ah, thanks. I'll make sure my server's sending that header to help Chrome out. Appreciate your help with this!
,
Oct 13 2012
This issue has been closed for some time. No one will pay attention to new comments. If you are seeing this bug or have new data, please click New Issue to start a new bug.
,
Mar 9 2013
,
Mar 10 2013
,
Mar 13 2013
,
Apr 6 2013
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by scherkus@chromium.org
, Oct 21 2010Status: Assigned