[#10193] String.ord — David Flanagan <david@...>

Hi,

41 messages 2007/02/05
[#10197] Re: String.ord — Yukihiro Matsumoto <matz@...> 2007/02/06

Hi,

[#10198] Re: String.ord — David Flanagan <david@...> 2007/02/06

Yukihiro Matsumoto wrote:

[#10199] Re: String.ord — Daniel Berger <djberg96@...> 2007/02/06

David Flanagan wrote:

[#10200] Re: String.ord — David Flanagan <david@...> 2007/02/06

Daniel Berger wrote:

[#10208] Re: String.ord — "Nikolai Weibull" <now@...> 2007/02/06

On 2/6/07, David Flanagan <david@davidflanagan.com> wrote:

[#10213] Re: String.ord — David Flanagan <david@...> 2007/02/06

Nikolai Weibull wrote:

[#10215] Re: String.ord — "Nikolai Weibull" <now@...> 2007/02/06

On 2/6/07, David Flanagan <david@davidflanagan.com> wrote:

[#10216] Re: String.ord — David Flanagan <david@...> 2007/02/07

Nikolai Weibull wrote:

[#10288] Socket library should support abstract unix sockets — <noreply@...>

Bugs item #8597, was opened at 2007-02-13 16:10

12 messages 2007/02/13

[#10321] File.basename fails on Windows root paths — <noreply@...>

Bugs item #8676, was opened at 2007-02-15 10:09

11 messages 2007/02/15

[#10323] Trouble with xmlrpc — James Edward Gray II <james@...>

Some of the Ruby code used by TextMate makes use of xmlrpc/

31 messages 2007/02/15
[#10324] Re: Trouble with xmlrpc — "Berger, Daniel" <Daniel.Berger@...> 2007/02/15

> -----Original Message-----

[#10326] Re: Trouble with xmlrpc — James Edward Gray II <james@...> 2007/02/15

On Feb 15, 2007, at 1:29 PM, Berger, Daniel wrote:

[#10342] Re: Trouble with xmlrpc — James Edward Gray II <james@...> 2007/02/16

While I am complaining about xmlrpc, we have another issue. It's

[#10343] Re: Trouble with xmlrpc — Alex Young <alex@...> 2007/02/16

James Edward Gray II wrote:

[#10344] Re: Trouble with xmlrpc — James Edward Gray II <james@...> 2007/02/16

On Feb 16, 2007, at 12:08 PM, Alex Young wrote:

Re: Trouble with xmlrpc

From: James Edward Gray II <james@...>
Date: 2007-02-16 16:07:57 UTC
List: ruby-core #10340
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


In This Thread