Re: The getcontentlength property

Mr. Demeanour wrote:
> 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.

Nope. Either DAV:getcontentlength is present (then it indicates the size 
after Transfer-Decoding) or it's not present. But if the server returns 
it, a client can use it.

That being said, the information from the actual GET request is always 
authoritative, be it a Content-Length response header, or the actual 
content length after reading the full body using Transfer-Encoding: chunked.

> ...
>> 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/.

Yep. The getcontentlength property is for things like directory 
listings. That's it.

> 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.

Right.

>> 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.

+1.