Re: The getcontentlength property

Werner Donné wrote:
> 
> Julian Reschke wrote:
>> Werner Donné wrote:
>>> 
>>> Hi,
>>> 
>>> RFC 2518 says that this property must be returned if the 
>>> Content-Length header is returned in a GET response for the
>>> resource at hand. I assume that it is allowed to return this
>>> property if the Content-Length header is never returned, for
>>> example, because the chunked transfer encoding is used.
>> 
>> Yes.
>> 
>>> Can a client rely on a previously retrieved getcontentlength to
>>> read only part of the chunked response stream of the following
>>> GET response?
>> 
>> If it has reason to believe that the entity didn't change
>> (ETag...), then yes.
>> 
>>> The particular case I have is where I detect the client is on a
>>> windows machine and is retrieving a text/plain resource. In that
>>> case carriage returns may be added on the fly. This increases the
>>> physical length of the resource.
>> 
>> By doing this you're serving two different variants, depending on
>> some part of the request ("User-Agent" header?)? So you'll have to
>> specify "Vary" header in the response, and assign different entity
>> tags. In that case a properly written client shouldn't have any
>> problems because it can detect that the entity served by the second
>> request is really different.
> 
> Yes, the "User-Agent" header was used.
> 
> The problem is when the resource is going to be fetched for the first
>  time by the client. It does a PROPFIND for retrieving the contents
> of the parent collection and then a GET. The client I'm trying it
> with doesn't ask for the "getetag" property in the PROPFIND, so
> whatever ETag returns, it can't draw any conclusions from it. It just
> uses the "getcontenttype" property to decide how many bytes to read,
> even if the response stream is chunked.

I take it you meant "uses the getcontentlength property to decide".

If this client is going to ignore the HTTP 1.1 protocol, and instead
decides to read from the wire the number of bytes given in the response
to an earlier request, then I wouldn't expect it to work at all with a
chunked stream; because the length of the stream depends on the
transfer-encoding; and in particular, chunked encoding changes to the
number of bytes that comprise the stream.

I must say, I'm rather puzzled by this question; the whole point of the
chunked encoding is that it is suited to transferring content for which
it is inconvenient to compute a length in advance. If you can know the
length in advance, can't you just get your server to transfer unencoded
data, and use a Content-Length: header?

I presume I've missed the point.

-- 
Jack.

Received on Friday, 22 June 2007 18:04:42 UTC