commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ortwin Glück <>
Subject Re: [httpclient] Content-Length handling
Date Wed, 18 Sep 2002 16:08:31 GMT
My point of view:

We should primarily stick to the RFCs. (Yes I know there are other 
interest groups who do server testing). If there are servers that have a 
faulty HTTP implementation that's their problem (which should be 
corrected), not ours. Better write to them :-)

But the actual problem here is more: How can we determine that the 
content-length was reported too small?

Imagine the following situation:
Server reports content-lenth 1000 bytes. The actual content is 1015 
bytes. After 10 bytes the server pauses (maybe because of network jam) 
and after some seconds the remaining 15 bytes arrive. There is 
absolutely no reason why the client should wait (for how long?) for more 
data after it has received the reported number of bytes.

So we can not detect this in general, right?


Ryan Hoegg wrote:
>  From RFC2616 4.4.4 :
> When a Content-Length is given in a message where a message-body is
> allowed, its field value MUST exactly match the number of OCTETs in
> the message-body. HTTP/1.1 user agents MUST notify the user when an
> invalid length is received and detected.
> Does this mean that HTTPClient should throw an exception when 
> Content-Length does not match the length of the response body?  Or do we 
> have some latitude here?
> My immediate concern is not for strict RFC enforcement but for 
> compliance with as many (possibly broken) HTTP server implementations as 
> possible.  What are the priorities for the committers?
> Ryan Hoegg
> ISIS Networks

  NOSE applied intelligence ag

  ortwin glück                      [www]
  hardturmstrasse 171               [email]
  8005 zurich                       [office]      +41-1-277 57 35
  switzerland                       [fax]         +41-1-277 57 12

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message