Compressing requests/results...

[Michael Landon - IBN]

We've been using xml-rpc for about a year now & are very impressed with its capabilities.  A problem, however, has been the increased bandwidth requirements when sending xml streams (as opposed to binary object streams).  The good thing, though, is that these xml streams are perfect candidates for compression.  So, if I could make a small request, maybe the XmlRpcClientLite & WebServer objects could incorporate the use of       Accept-Encoding: gzip and     Content-Encoding: gzip   headers.  Here's how I could see it functioning:   The client's request would include the "Accept-Encoding: gzip" header.  The server would always look for that header...and if found, the server would encode the response w/ the built in Java GZIPOutputStream object and then include the "Content-Encoding: gzip" header w/ the results.   Alternatively, if the incoming client's request included the "Content-Encoding: gzip" header, the server would decode the request w/ the built in Java GZIPInputStream object & respond as above.   If neither header is not found, the server responds as normal (no compression), but includes the "Accept-Encoding: gzip" header w/ its results.    Back on the client side, if the client receives results w/ the "Content-Encoding: gzip" header, it would decode the results w/ the built in GZIPInputStream object.  From that point on, the client would always send compressed requests (including the "Content-Encoding: gzip" header).   If the client receives the "Accept-Encoding" header from the server, the client would process the results as normal (no decompression) but from that point on would compress all requests.   I think this method would allow for full backward compatibility w/ older versions of xmlrpc and not break any spec rules.  It just seems like such a simple enhancement with many benefits.  Thoughts?   Michael