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
