On Feb 16, 2007, at 9:33 AM, zdennis wrote:

> According to HTTP1.1 RFC
>
> Section 4.4...

>    "For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
>    containing a message-body MUST include a valid Content-Length  
> header
>    field unless the server is known to be HTTP/1.1 compliant."

This quote is actually referring to clients sending messages to the  
server, so the MUST doesn't affect us in this case.

> Section 14.13...
>
>   "Applications SHOULD use this field to indicate the transfer- 
> length of
>    the message-body, unless this is prohibited by the rules in section
>    4.4."

Quoting from RFC 2119 (http://rfc.net/rfc2119.html):

3. SHOULD  This word, or the adjective "RECOMMENDED", mean that there  
may exist valid reasons in particular circumstances to ignore a  
particular item, but the full implications must be understood and  
carefully weighed before choosing a different course.

> I don't know if this helps, but it seems in most cases the Content- 
> Length *should* be there unless Transfer-Encoding header
> exists, then it could be ignored or ommitted.

The way I see it is that we know two things for sure:

1.  There are circumstances where the field is not required
2.  This issue arose because some services are not providing it

If we want to be liberal in what we accept, which seems right for a  
standard library, we need to make the header optional.  This doesn't  
change a thing for the good services that provide the header, so the  
only effect this can possibly have is that xmlrpc/client.rb will work  
with more services.  I call that a win.

James Edward Gray II