Re: [FileAPI] blob: protocol need a content-length header
Benjamin, I filed the following: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18548 I think we should add Content-Length. -- A* On Aug 12, 2012, at 5:41 PM, Benjamin BERNARD wrote: > I build de demo script (for firefox) here : > http://experiments.benvii.com/blob_content_length/ > You will also notice that the player's load event isn't called. > > Content-Length should be added to firefox (maybe open a ticket on > https://bugzilla.mozilla.org/) but it should also be recommended in the > section "11.7.3. Request and Response Headers" of the spec. > > Thanks for responding. > > Benjamin BERNARD > > > Le 12/08/2012 21:23, Jonas Sicking a écrit : >> On Sun, Aug 12, 2012 at 2:56 AM, Benjamin BERNARD >> wrote: >>> Hi, >>> I was developing an offline music web App when I discover that is no >>> "Content-length" header specified here : >>> http://www.w3.org/TR/FileAPI/#ProtocolExamples >>> So when you play an audio/video file stored as a blob (under a blob URI) >>> it's considered by the player as streaming content which means you can't get >>> the duration of a song for instance (it has an infinite duration). I think >>> it might be the consequence of not providing a content-length header. >>> >>> I experienced it using Firefox I heard Internet Explorer already provide >>> this header. >>> >>> Moreover, I don't understand why there is no content-length header >>> recommended in the spec because when you use URL.createObjectURL(blob), blob >>> has a finished size (correct me if I'm wrong). So a content-length header >>> should also be provided and recommended in the spec. >> Yes, I agree, we should have a content-length header similar to the >> content-type header. >> >> In Gecko things are a bit complicated because we don't have headers on >> anything but http channels. But we do have the concept of a length of >> a response for all channels so that should take care of it. Not sure >> off the top of my head why it doesn't. Filing a bug with an example >> would be great. >> >> / Jonas >
Re: [FileAPI] blob: protocol need a content-length header
I build de demo script (for firefox) here : http://experiments.benvii.com/blob_content_length/ You will also notice that the player's load event isn't called. Content-Length should be added to firefox (maybe open a ticket on https://bugzilla.mozilla.org/) but it should also be recommended in the section "11.7.3. Request and Response Headers" of the spec. Thanks for responding. Benjamin BERNARD Le 12/08/2012 21:23, Jonas Sicking a écrit : On Sun, Aug 12, 2012 at 2:56 AM, Benjamin BERNARD wrote: Hi, I was developing an offline music web App when I discover that is no "Content-length" header specified here : http://www.w3.org/TR/FileAPI/#ProtocolExamples So when you play an audio/video file stored as a blob (under a blob URI) it's considered by the player as streaming content which means you can't get the duration of a song for instance (it has an infinite duration). I think it might be the consequence of not providing a content-length header. I experienced it using Firefox I heard Internet Explorer already provide this header. Moreover, I don't understand why there is no content-length header recommended in the spec because when you use URL.createObjectURL(blob), blob has a finished size (correct me if I'm wrong). So a content-length header should also be provided and recommended in the spec. Yes, I agree, we should have a content-length header similar to the content-type header. In Gecko things are a bit complicated because we don't have headers on anything but http channels. But we do have the concept of a length of a response for all channels so that should take care of it. Not sure off the top of my head why it doesn't. Filing a bug with an example would be great. / Jonas
Re: [FileAPI] blob: protocol need a content-length header
On Sun, Aug 12, 2012 at 2:56 AM, Benjamin BERNARD wrote: > Hi, > I was developing an offline music web App when I discover that is no > "Content-length" header specified here : > http://www.w3.org/TR/FileAPI/#ProtocolExamples > So when you play an audio/video file stored as a blob (under a blob URI) > it's considered by the player as streaming content which means you can't get > the duration of a song for instance (it has an infinite duration). I think > it might be the consequence of not providing a content-length header. > > I experienced it using Firefox I heard Internet Explorer already provide > this header. > > Moreover, I don't understand why there is no content-length header > recommended in the spec because when you use URL.createObjectURL(blob), blob > has a finished size (correct me if I'm wrong). So a content-length header > should also be provided and recommended in the spec. Yes, I agree, we should have a content-length header similar to the content-type header. In Gecko things are a bit complicated because we don't have headers on anything but http channels. But we do have the concept of a length of a response for all channels so that should take care of it. Not sure off the top of my head why it doesn't. Filing a bug with an example would be great. / Jonas
[FileAPI] blob: protocol need a content-length header
Hi, I was developing an offline music web App when I discover that is no "Content-length" header specified here : http://www.w3.org/TR/FileAPI/#ProtocolExamples So when you play an audio/video file stored as a blob (under a blob URI) it's considered by the player as streaming content which means you can't get the duration of a song for instance (it has an infinite duration). I think it might be the consequence of not providing a content-length header. I experienced it using Firefox I heard Internet Explorer already provide this header. Moreover, I don't understand why there is no content-length header recommended in the spec because when you use URL.createObjectURL(blob), blob has a finished size (correct me if I'm wrong). So a content-length header should also be provided and recommended in the spec. Thanks in advance, -- Benjamin BERNARD
