546700 - Ogg video fails to load when server lies about accepting range requests

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Ben Schwartz]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4) Gecko/20091205 Gentoo Firefox/3.5.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4) Gecko/20091205 Gentoo Firefox/3.5.4

I tried to play this video URL in Firefox and it utterly failed. It just spins forever, apparently trying to buffer but not succeeding.  Downloading the same video in wget, even using -U to enforce the same User-Agent string as Firefox, works perfectly.  This behavior has been consistent for every Ogg video I have encountered.

My best guess for this is that I am behind an http proxy here at work (almost sure), and that this proxy is somehow mangling range requests (total guess).  That, I think, could explain why wget would work, but Firefox would fail.

Anyway, whatever the cause is, Firefox should handle this more gracefully.  If wget works, Firefox should work too.

Reproducible: Always

Comment 1

[Matthias Versen [:Matti]]

>Anyway, whatever the cause is, Firefox should handle this more gracefully.  If
>wget works, Firefox should work too.

I disagree if Gecko really uses range requests and your proxy fails.
But whatever, a http log my help :
https://developer.mozilla.org/en/HTTP_Logging

Comment 2

[Ben Schwartz]

Attachment: gzip'd HTTP Log

This is the HTTP log when firefox fails to play a video.  I stopped it after it grew to 3 MB of log.

Comment 3

[Christophe Humbert]

Hello,

For me, behind a proxy which is an isa server It is working like a charm

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Kind Regards

Comment 4

[Tyler Downer [He/Him]]

Reporter, are you still seeing this issue with Firefox 3.6.13 or later in safe mode? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles

You can also try to reproduce in Firefox 4 Beta 8 or later, there are many improvements in the new version, http://www.mozilla.com/en-US/firefox/all-beta.html

Comment 5

[Tyler Downer [He/Him]]

No reply, INCOMPLETE. Please retest with Firefox 3.6.13 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.

Comment 6

[Ben Schwartz]

Re-tested in FF 3.6.13, fresh profile, with and without safe mode.  No real improvement in behavior is detectable.  Most videos don't even load.

Comment 7

[Ben Schwartz]

Re-tested in FF 4.0b10 on Windows 7.  Same bad behavior.  For example browsing to 

http://media.xiph.org/basilgohar/timelapse/work-clouds-vga-30fps-q7.ogv

does not even pop up a gray box of the correct size, and the video never plays.  However, downloading this file with wget on the same network works perfectly.

Incidentally, the network in question is filtered by a Cisco IronPort appliance.  I don't know whether there are any other filters in place.

Comment 8

[Matthias Versen [:Matti]]

Sorry, I somehow missed the http log

Comment 9

[Boris Zbarsky [:bzbarsky]]

So the log is showing us making a GET request like so:

GET /~blizzard/weblog-videos/2010-02-14-difference-engine/VID00212.ogv HTTP/1.1

and getting back a response which has:

  Content-Length: 13989970

Then we do another request like so:

GET /~blizzard/weblog-videos/2010-02-14-difference-engine/VID00212.ogv HTTP/1.1
Range: bytes=13983744-

(trying to read the ogg metadata) and getting back a 200 (not 206) response like so:

  Content-Length: 13989970

Then we repeat this last bit 100-some times.  But it never gets better.  ;)

This is definitely NOT an HTTP issue, and I was pretty sure we handled lack of Range support in the media code, so what gives?

Comment 10

[cajbir (:cajbir)]

I think we blindly believe the server if it sends an Accept-Ranges:bytes header which the logs seem to show that this server does. We should possibly cancel that belief if we find out the server lied.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Ah, yeah, that seems like a good idea.  The proxy is all kinds of broken, but still....

Comment 12

[Ben Schwartz]

A brief google finds one other instance of someone being bitten by Ironport's range-request lies.  Similar problem, same diagnosis.

http://lists.opensuse.org/opensuse/2010-03/msg00461.html

Comment 13

[Ben Schwartz]

According to

http://aicheh.files.wordpress.com/2010/05/wsa_6-3-3_ga_release_notes.pdf (page 32)

this bug was fixed in Ironport 6.0.0, which is a few years old but does not appear to be prehistoric.

Comment 14

[Matthew Gregan [:kinetik]]

Attachment: patch v0

If the server sends Accept-Ranges and we've received an HTTP 200 back from an attempted range request, mark the stream as not seekable.

Requesting approval since this is a simple, fairly safe patch that avoids an awful case for a small set of users.

Comment 15

[Matthew Gregan [:kinetik]]

http://hg.mozilla.org/mozilla-central/rev/d30bc9781cfd

Comment 16

[u279076]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12) Gecko/20100101 Firefox/4.0b12

Something seems broken with the two test cases.  I'm not sure if this is related to this bug or not:

http://www.0xdeadbeef.com/~blizzard/weblog-videos/2010-02-14-difference-engine/VID00212.ogv
http://media.xiph.org/basilgohar/timelapse/work-clouds-vga-30fps-q7.ogv

Both buffer and play as expected, but the video pauses when the mouse cursor is not over the video and resumes when the mouse cursor is on top of the video.

Comment 17

[Matthew Gregan [:kinetik]]

This is covered by a mochitest, so it should be fine to mark as verified.

I can reproduce the other bug you're seeing--it seems like a variation of bug 633261, but that is OpenGL specific (and requires closing and reopening a tab).  I can reproduce it on Windows with D3D10 without reopening a tab, so it's not exactly the same bug.  Would you mind filing a new bug in Core::Graphics and requesting blocking?

Comment 18

[u279076]

Verified fixed as per comment 17.  Will file a followup bug.

Comment 19

[u279076]

See bug 636817.