Re: content-type

John Wilson <[email protected]> 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.
>
> I think the firewall example is very unconvincing. Anybody who used that rule and expected to stop XML-RPC calls would get what they deserved.
>
> Nice to see a question on XML-RPC implementation, the first in (literally) years :)
>
So, let's jump in and have a little discussion! :-)

While I agree with the above, 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, to be able to create a generic-webservice-endpoint supporting multiple protocols.

Currently the logic used by ws endpoints to decide when to execute, when to show wsdl, when to show human-readable docs is, afaik, custom built for every 
library/service, and often brittle.

A "standard algorithm" could be a good idea for interoperability.

bye
Gaetano

> John Wilson
>



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



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

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:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/