headers
Bryan Henderson | 15 Nov 2010 04:15

content-type

The XML-RPC spec says the HTTP content type of an XML-RPC call or response is
text/xml and, if you squint, says the content-type header field has to be
there.

But what do people think an XML-RPC server ought to do with a call that is
otherwise XML-RPC but lacks the content-type header field or says the content
type is something else, e.g. text/plain?

A comment from long ago in the source code of XML-RPC For C and C++ says the
server should reject the call as malformed for this reason: the server's
network security filters may turn away POST requests of type text/xml with the
intention of stopping XML-RPC calls, so processing a call that doesn't state
text/xml would defeat that filter.  And XML-RPC For C and C++ has in fact
always rejected calls that don't say content-type: text/xml.

On the other hand, being liberal in what you accept is the general rule, and
makes for higher interoperability.  This question came up because I
encountered a supposed XML-RPC client that does in fact indicate content-type:
text/plain .

--

-- 
Bryan Henderson                                   San Jose, California

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/xml-rpc/
(Continue reading)

Permalink | Reply | 4 comments |
headers
John Wilson | 15 Nov 2010 10:11
Picon

Re: content-type


On 15 Nov 2010, at 03:15, Bryan Henderson wrote:

> The XML-RPC spec says the HTTP content type of an XML-RPC call or response is
> text/xml and, if you squint, says the content-type header field has to be
> there.
> 
> But what do people think an XML-RPC server ought to do with a call that is
> otherwise XML-RPC but lacks the content-type header field or says the content
> type is something else, e.g. text/plain?
> 
> A comment from long ago in the source code of XML-RPC For C and C++ says the
> server should reject the call as malformed for this reason: the server's
> network security filters may turn away POST requests of type text/xml with the
> intention of stopping XML-RPC calls, so processing a call that doesn't state
> text/xml would defeat that filter.  And XML-RPC For C and C++ has in fact
> always rejected calls that don't say content-type: text/xml.
> 
> On the other hand, being liberal in what you accept is the general rule, and
> makes for higher interoperability.  This question came up because I
> encountered a supposed XML-RPC client that does in fact indicate content-type:
> text/plain .

My view is that the server should ignore content-type.

In practice you have to disregard part of the meaning of content-type: text/xml anyway. The charset
parameter is omitted so you are supposed use US-ASCII (http://www.ietf.org/rfc/rfc3023 section 3.1)
as the character encoding and nobody does that.

I think the firewall example is very unconvincing. Anybody who used that rule and expected to stop XML-RPC
(Continue reading)

Permalink | Reply | 3 comments |
headers
Gaetano Giunta | 15 Nov 2010 10:29
Picon
Gravatar

Re: content-type

John Wilson <tug <at> wilson.co.uk> wrote on 15/11/2010 10:11:
>
>
> On 15 Nov 2010, at 03:15, Bryan Henderson wrote:
>
> > The XML-RPC spec says the HTTP content type of an XML-RPC call or response is
> > text/xml and, if you squint, says the content-type header field has to be
> > there.
> >
> > But what do people think an XML-RPC server ought to do with a call that is
> > otherwise XML-RPC but lacks the content-type header field or says the content
> > type is something else, e.g. text/plain?
> >
> > A comment from long ago in the source code of XML-RPC For C and C++ says the
> > server should reject the call as malformed for this reason: the server's
> > network security filters may turn away POST requests of type text/xml with the
> > intention of stopping XML-RPC calls, so processing a call that doesn't state
> > text/xml would defeat that filter. And XML-RPC For C and C++ has in fact
> > always rejected calls that don't say content-type: text/xml.
> >
> > On the other hand, being liberal in what you accept is the general rule, and
> > makes for higher interoperability. This question came up because I
> > encountered a supposed XML-RPC client that does in fact indicate content-type:
> > text/plain .
>
> My view is that the server should ignore content-type.
>
> In practice you have to disregard part of the meaning of content-type: text/xml anyway. The charset
parameter is omitted so you are supposed use US-ASCII 
> (http://www.ietf.org/rfc/rfc3023 section 3.1) as the character encoding and nobody does that.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bryan Henderson | 15 Nov 2010 17:07

Re: discerning multiple protocols

>it would be nice if there was some (set of?) request headers that could be
>used in a meaningful way to discern between soap, xmlrpc, jsonrpc and plain
>rest requests that are sent to the same url

Why would that be better than having separate URLs for the separate
protocols?

I thought the point of /RPC2 in the URL was to say, "execute this as XML-RPC".

-- 
Bryan Henderson                                   San Jose, California

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/xml-rpc/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/xml-rpc/join
    (Yahoo! ID required)

<*> To change settings via email:
    xml-rpc-digest <at> yahoogroups.com 
    xml-rpc-fullfeatured <at> yahoogroups.com
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gaetano Giunta | 17 Nov 2010 10:20
Picon
Gravatar

Re: discerning multiple protocols

Bryan Henderson <bryanh <at> giraffe-data.com> wrote on 15/11/2010 17:07:
>
> >it would be nice if there was some (set of?) request headers that could be
> >used in a meaningful way to discern between soap, xmlrpc, jsonrpc and plain
> >rest requests that are sent to the same url
>
> Why would that be better than having separate URLs for the separate
> protocols?
>
For the fun of it?

Seriously, it makes it easier to provide a "ws toolkit" that can be integrated as part of other
frameworks/cms/applications if all you need to deploy is a 
single controller file and not 3 or 4.

Bye
Gaetano

>
> I thought the point of /RPC2 in the URL was to say, "execute this as XML-RPC".
>
> -- 
> Bryan Henderson San Jose, California
>
> 

[Non-text portions of this message have been removed]

------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |

Gmane