Streaming mode not working as documented
----------------------------------------
Key: XMLRPC-148
URL: https://issues.apache.org/jira/browse/XMLRPC-148
Project: XML-RPC
Issue Type: Bug
Affects Versions: 3.1
Environment: Gentoo / Sun JDK 1.6
Reporter: Andreas Sahlbach
Here is my mail posted in the developer mailing list describing the issue(s):
Hi xmlrpc-gurus!
I am trying to migrate my projects from xmlrpc 2.0 to xmlrpc 3.1. I need to
migrate one of the clients and the server, so I am very interested, that this
part of the documentation is true:
> If streaming mode is disabled, then the server will always behave like a
> standard XML-RPC server. Otherwise, the server will verify, whether the
> client sends a content-length header. 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 still disable streaming for this
> particular requests. In other words, traditional clients will still receive a
> traditional > response and one server can serve both data types.
Unfortunately during verification of this I encountered two problems:
1) client: I am using the sun classes on a linux system. It looks like that it
doesn't actually matters if I set contentLengthOptional and
enabledForExtensions to tue or false. The request _always_ contains a
content-length header. I debugged it but couldn't find place, where this header
is added. I found the place in the client where the configuration was correctly
read out and where the client was skipping the part to add this header. But
nevertheless my request contains a content-length header at the end (I am using
wireshark to sniff the network traffic). In the case I set the two
configurations to true, the content-length header is always the last header in
the header section. Can it be, that java is adding the content-length header by
itself? If this is the case then using the content-length header for detection
if the server should answer in streaming mode or not is not working!
2) server: I actually can't find the part in the sources where the server is
honoring the content-length header in the request. It looks like the server is
acting in streaming mode if I set both options to true and is not acting in
streaming-mode, if I set both options to false. At least that is wireshark
telling me. Could you give me a pointer to the code part that is doing the
magic as stated in the documentation?
I don't want to nit-pick, but not becoming incompatible is essential for my
service. Within the enterprise of my customer a number of clients are not under
my control and I am in deep shit if they stop working :)
Thanks for your time guys!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
