[Ffmpeg-devel] HTTP probing issue... [PATCH]

[Michael Niedermayer]

Hi

On Tue, Feb 27, 2007 at 07:27:01PM +0100, Baptiste Coudurier wrote:
> Hi
> 
> Ryan Martell wrote:
> > On Feb 20, 2007, at 9:02 PM, Ryan Martell wrote:
> >> On Feb 20, 2007, at 7:39 PM, Michael Niedermayer wrote:
> >>> On Tue, Feb 20, 2007 at 04:32:39PM -0600, Ryan Martell wrote:
> >>>>
> >>>> Patch will cause http_read to respect the file size if it came down
> >>>> in the header, and only read up to that number of bytes.  If the
> >>>> Content-Length or Content-Range was not set, this does nothing.
> >>>
> >>> rejected, no fix will be accpted until the problem is understood
> >>> especially
> >>> not one depending on a optional header
> >>>
> >>> i suggest you try a binary search in svn versions to find out when this
> >>> broke, i think someone said it worked in the past, id also take a
> >>> carefull look at os_support.* and related changes
> >>
> >> Well, I can try and look for it some more. While trying to figure out
> >> what had happened I was looking over everything, but nothing jumped
> >> out at me.  And unfortunately while merging this in I lost my ffmeg
> >> revision number, so I don' t have a good place to start looking.
> >>
> >> os_support doesn't seem to have anything that would address that; I'm
> >> running on MacOSX, so essentially a *nix build.
> >>
> >> Either way, I think the patch is useful.  It allows for returning
> >> immediately rather than doing any timeout or network calls if it knows
> >> the length of the file in advance, and it allows for asking for the
> >> exact length at the end of the file.  If it knows nothing, it does
> >> nothing, so there shouldn't be any side effects.  And it doesn't do
> >> anything that's based on weird thread sychronicity issues like sleep().
> > 
> > I narrowed the problem down.  If you change HTTP/1.1 back to HTTP/1.0
> > (as it was before Ronald's patch) it works just fine.  However, this
> > will make the Range: be in non-compliance, and break the HTTP seeking.
> > 
> > From HTTP/1.1:
> > 
> > Content-Length:
> >  Applications SHOULD use this field to indicate the transfer-length of
> > the message-body, unless this is prohibited by the rules in section 4.4.
> > 
> > Any Content-Length greater than or equal to zero is a valid value.
> > Section 4.4 describes how to determine the length of a message-body if a
> > Content-Length is not given.
> > 
> > 
> > From section 4.4:
> > 
> > For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
> > containing a message-body MUST include a valid Content-Length header
> > field unless the server is known to be HTTP/1.1 compliant. If a request
> > contains a message-body and a Content-Length is not given, the server
> > SHOULD respond with 400 (bad request) if it cannot determine the length
> > of the message, or with 411 (length required) if it wishes to insist on
> > receiving a valid Content-Length.
> > 
> > All HTTP/1.1 applications that receive entities MUST accept the
> > "chunked" transfer-coding (section 3.6), thus allowing this mechanism to
> > be used for messages when the message length cannot be determined in
> > advance.
> > 
> > Messages MUST NOT include both a Content-Length header field and a
> > non-identity transfer-coding. If the message does include a non-
> > identity transfer-coding, the Content-Length MUST be ignored.
> > 
> > When a Content-Length is given in a message where a message-body is
> > allowed, its field value MUST exactly match the number of OCTETs in the
> > message-body. HTTP/1.1 user agents MUST notify the user when an invalid
> > length is received and detected.
> > 
> > As my patch stands, it checks if Content-Length has been defined, and if
> > so, uses it.
> > 
> > So, what do you want me to do?
> > 
> 
> Ok, I dig svn and found out something. See patch attached.
> Basically http_seek returns -1 (like file_seek), and then url_fseek will
> return -1 instead of EPIPE, and that will make probing fail:
> 
> if (url_fseek(pb, 0, SEEK_SET) == (offset_t)AVERROR(EPIPE)) {
>     url_fclose(pb);
>     if (url_fopen(pb, filename, URL_RDONLY) < 0) {
> 
> Should probe check for negative ret, or url_fseek should return EPIPE ?
> I reestablished EPIPE ret.

probe of course should check for <0 as it doesnt matter at all why seek
failed

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070301/79e64971/attachment.pgp>