Re: The getcontentlength property

Julian Reschke wrote:
> Mr. Demeanour wrote:
>> 
>> Werner Donné wrote:
>>> Mr. Demeanour wrote:
>>>> 
>>>> I presume I've missed the point.
>>>> 
>>> 
>>> This client does seem to read the chunked stream correctly, but
>>> after reading it, it only retains as much bytes as indicated by
>>> the "getcontentlength" property, which was fetched earlier.
>> 
>> That's clearly a defect in the client. The server can't be expected
>> to compute a getcontentlength that may be dependent on whatever 
>> Transfer-Encoding it decides on later (since the Transfer-Encoding
>> may be dependent on some Accept: header it hasn't seen yet).
> 
> Um, the value of content-length header as defined in RFC2616 does not
>  depend on the transfer encoding.

Agreed. But it's meaning does; in the presence of Transfer-Encoding:
chunked, Content-Length: should be ignored. I would suppose that means
that getcontentlength should also be ignored in those circumstances.
> 
>> But this is partly missing the point, I think. Your server is
>> sending a getcontentlength value for an entity which is dependent
>> on the User-Agent; but it seems to be generating the same
>> getcontentlength value, regardless of which entity is being
>> requested (i.e. regardless of the User-Agent setting). If you are
>> going to vary the entity's value according to the User-Agent, then
>> surely you should vary the value of getcontentlength according to
>> the same criteria.
> 
> I'd like to agree with this, but unfortunately RFC2518 has this
> language in
> (<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.13.4>):
> 
> "Purpose: Contains the Content-Length header returned by a GET
> without accept headers."

Hah - OK. So Werner's client shouldn't be using getcontentlength to
control the transfer process /at all/.

Suppose that instead of a simple UA-dependent transformation of CRs into
CRLFs, the various entities that might be returned were translations
into various languages of some text? Without accept headers, the
getcontentlength value could represent any one of the renditions, chosen
arbitrarily. But if the browser submits an Accept-Language: header, and
the rendition chosen for the computation doesn't happen to match that
header, then there would be no correspondence whatsoever between the two
lengths.
> 
> Now U-A is not an accept header, but it *seems* like the original
> intent was to forbid variant selection here. Problem is, nobody seems
> to recall why this was added, and what exactly it means.
> Unfortunately, we have the same confusing language in 
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-18.html#rfc.section.15.4>,
>  soon to be published as RFC4918.

So I'm inclined to interpret it as meaning that getcontentlength gives
the size of some entity of the resource, but which entity is undefined.
In particular, its value is unsuitable for controlling a transfer.


-- 
Jack.

Received on Saturday, 23 June 2007 11:35:47 UTC