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

[Ryan Martell]

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?

Thanks,
-Ryan