[
https://issues.apache.org/jira/browse/XMLRPC-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538236
]
Jochen Wiedmann commented on XMLRPC-148:
----------------------------------------
I have studied your patch. I agree that it ensures that the server behaves as
documented.
However, judging from your observations on the clients behaviour, we currently
have no reliable way to enforce that the server replies in streaming mode. This
is bad.
I think that we should add an additional possibility to enforce the servers
behaviour. For example, I could imagine that the client might add an attribute
ex:contentLengthOptional="true"
with ex indicating the namespace
http://ws.apache.org/xmlrpc/namespaces/extensions to the request document.
Would you be ready to create a patch for that? I have added your patch, btw.
> 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
> Attachments: xmlrpc.patch
>
>
> 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.
