Re: The problem of having multiple Content-Range headers in HTTP response

2010/3/4 Raphaël Troncy <raphael.troncy@eurecom.fr>:
>> the comma thing is not about "will be parsed to", but "is equivalent
>> to". So, an application could add the two headers in order:
>>
>> Content-Range: track audio
>> Content-Range: subtitle/653.791
>
> My understanding was: this is invalid since we cannot have multiple
> Content-Range headers in a response. Now, you just verbatim in another email
> a paragraph from RFC2616 (Section 4.2 Message Headers) that seems to say
> that this is *valid*. So I'm now confused.
> Yves, could you please provide us a pointer that reference your original
> claim?

I don't think there is a contradiction any longer with what Conrad posted.

There is only one Content-Range header, but it can be split over
several Content-Range header fields and recombined by adding a comma.
We just cannot use several Content-Range headers for different things,
such as in the current spec with it being used to also signify what
the original ranges were.

So, I think all we have to do is change the field names and we have to
make sure we find a better separator than a comma for lists of tracks.

I volunteer to make the change on the field name (seeing as I
introduced the problem).

Cheers,
Silvia.

Received on Thursday, 4 March 2010 09:23:31 UTC