W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2007

Re: The getcontentlength property

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 23 Jun 2007 11:35:34 +0200
Message-ID: <467CE966.7070607@gmx.de>
To: "Mr. Demeanour" <mrdemeanour@jackpot.uk.net>
CC: w3c-dist-auth@w3.org

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.

> 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>):

     Contains the Content-Length header returned by a GET without accept 

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 
soon to be published as RFC4918.

Best regards, Julian
Received on Saturday, 23 June 2007 09:35:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:41 UTC