- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 23 Jun 2007 15:28:27 +0200
- To: "Mr. Demeanour" <mrdemeanour@jackpot.uk.net>
- CC: w3c-dist-auth@w3.org
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.
Received on Saturday, 23 June 2007 13:28:42 UTC