xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Hoegg <rho...@isisnetworks.net>
Subject Re: http headers
Date Thu, 12 Sep 2002 19:54:33 GMT
John Wilson wrote:

>Chunking, whilst a very nice feature, is explicitly forbidden by the XML-RPC
>spec. (http://www.xml-rpc.com/spec see the Header Requirements section -
>"The Content-Length must be specified and must be correct").
>
>We already do some things which are explicitly forbidden by the XML-RPC
>spec. (using ISO 8859/1 encoding, for example). However this is done in a
>way which minimises the impact on interoperability.
>
>If we are going to support chunking, compression, etc. we must be sure that
>it has zero impact on interoperability.
>
>Could you give us an impact assessment of the changes that you are proposing
>on the interoperability with existing XML-RPC systems.
>
>John Wilson
>The Wilson Partnership
>http://www.wilson.co.uk
>

No problem, and you are right about the spec.  I also agree with you on 
interoperability.

The change I am proposing is to build in full HTTP/1.1 support to the 
client piece.  This is in order to increase interoperability with 
service providers that do not adhere to the strict XML-RPC spec with 
their software.  For example, from the documentation for a service I 
need to consume: "The XML-RPC spec states that all responses must 
specify a predetermined response length using the HTTP Content-Length: 
header.  [My vendor] uses a more generalized form that allows the 
content length to be specified in any way that is valid for the version 
of HTTP that is being used."

It seems to be that we should be strict in what we send and lenient in 
what we accept (I think that's a Vixie quote, but don't "quote" me).  In 
other words, our client should only send strictly compliant requests but 
accept less compliant responses if possible.  I think this is possible 
with the Jakarta Commons HttpClient.  However, I don't think that it 
offers much benefit to build this into the XmlRpcClientLite.

Some specific HTTP/1.1 features that should be included are chunking, 
compression, authentication, and cookies.  I am only talking about a 
client here; our server should strictly follow the spec.  This doesn't 
necessarily rule out compression, incidentally.

Before I break my back filling out javadoc and making exhaustive test 
suites, please let me know if the committers think this is not a good 
fit for this library.

--
Ryan Hoegg
ISIS Networks



Mime
View raw message