[
https://issues.apache.org/jira/browse/XMLRPC-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Burlison updated XMLRPC-148:
---------------------------------
Comment: was deleted
(was: I suspect that streaming mode is incompatible with HTTP 1.1 keepalives -
from http://java.sun.com/j2se/1.5.0/docs/guide/net/http-keepalive.html
----------
What makes a connection reusable?
Since TCP by its nature is a stream based protocol, in order to reuse an
existing connection, the HTTP protocol has to have a way to indicate the end of
the previous response and the beginning of the next one. Thus, it is required
that all messages on the connection MUST have a self-defined message length
(i.e., one not defined by closure of the connection). Self demarcation is
achieved by either setting the Content-Length header, or in the case of chunked
transfer encoded entity body, each chunk starts with a size, and the response
body ends with a special last chunk.
----------
)
> 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: streaming.patch, 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.
