Re: The getcontentlength property

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.

> 
> Best regards, Julian
> 

Regards,

Werner.
-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be

Received on Friday, 22 June 2007 14:46:20 UTC