You need to set the client properties enabledForCompression and gzipRequesting to achieve that.Įnabling vendor extensions means also, that several additional data types may be sent. In other words, the client must send this header. Additionally, the server will read the HTTP header Accept-Encoding: If it doesn't contain gzip encoding, then compression cannot take place.
First of all, the server will only send a compressed response, if the server property enabledForExtensions is set. Needless to say, you may only do so, if the server is ready to accept such requests.Ĭompressing the request doesn't mean that the response is compressed as well. The XML-RPC request will be compressed (on-the-fly in streaming mode, of course) and the HTTP header Content-Encoding will be set to gzip. If the client should compress the response, then you need to set the properties enabledForExtensions and gzipCompressing. Of course, it's more convenient to have the XML-RPC library doing this. For example, the Apache httpd does so by using the mod_deflate module. In other words, it is quite likely, that request compression is supported by your HTTP client or server library. HTTP Request compression is a standard HTTP feature and works by using the HTTP headers Accept-Encoding and Content-Encoding. In other words, traditional clients will still receive a traditional response and one server can serve both data types. Otherwise, the server will still disable streaming for this particular requests. If so, then the server assumes that the client is able to accept a missing content-length header in the response as well. Otherwise, the server will verify, whether the client sends a content-length header. Currently, the server behaves as follows: If streaming mode is disabled, then the server will always behave like a standard XML-RPC server. On the server, things are a little bit more complicated. This will take care for the request, which is being sent to the server. To enable streaming mode on the client, set the properties enabledForExtensions and contentLengthOptional. (There are few other base64 encoders around, which support streaming mode.) But there is more: For example, the base64 encoder is also writing directly without internal buffering. Without streaming mode, this is always the case. In particular, the request, or response, isn't written to a ByteArrayOutputStream internally. (Besides, of course, using a moderately sized BufferedOutputStream, because one would not want to have a network connection for any write() call.) Putting the client or the server into streaming mode means, that data being sent to the other side is almost directly written to the network connection. Nothing is fixed, and everything can be changed. You'r welcome.īut the purpose of this document is more than documentation: It is also to receive feedback and discuss the extensions specification and implementation. Besides, the vendor extensions are documented very clearly here: Adding these features to an existing XML-RPC library would mean almost no effort, so possibly someone does. In practice, it occurs very frequently, that both sides are controlled by the same people. Of course, these features only work, if you have a streaming version of Apache XML-RPC on both sides. However, you may enable additional features, called vendor extensions. Version 3 of Apache XML-RPC is a compromise: By default it still meets the specification. But calculating the header value enforces, that request and response are written to byte arrays, before actually sending them.
Of course, having an additional header wouldn't be too much of a problem. Consequently, the content-length header is, at best, superfluos. Possibly even more important is the requirement to send a content-length header: HTTP/1.1 and its chunk encoding are the definite standard in 2005 for both HTTP clients and servers. For example, one cannot even use all of Java's primitive data types, although nowadays they have equivalents in almost any programming language. On the other hand, this is most unfortunate: Obeying the specification means accepting really serious limitations. Clearly, this target has been met and any further development would mean putting this at risk. Of course, he did so with a good reason: One of XML-RPC's major targets was portability over arbitrary platforms and programming languages. Dave Winer, the XML-RPC specifications author, has always rejected any suggestions in that direction. However, it hasn't really changed or evolved. In the past 6 years, it was subject to some minor corrections. The XML-RPC specification has been published in 1999.
0 kommentar(er)
