[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlrpc-dev
Subject:    [jira] Updated: (XMLRPC-148) Streaming mode not working as
From:       "Alan Burlison (JIRA)" <xmlrpc-dev () ws ! apache ! org>
Date:       2009-05-10 15:24:45
Message-ID: 185155671.1241969085643.JavaMail.jira () brutus
[Download RAW message or body]


     [ 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.


[prev in list] [next in list] [prev in thread] [next in thread]