Thanks so much for the reply! I'm accepting this as a solution, as I think there is value in your response to handling/decoding chunked data.
Our developer is finding that it is not only the payload that is chunked, rather the entire SOAP envelope, which makes handling the response much more difficult.
One work around we have found, however, is to generate the client stubs using Axis2, vs. the ClientGen ANT task for BEA, which results in a client that is able to marshal the chunked response, trasnparent to the developer.
Thanks again for your consideration in responding. I will close this issue.
Best Regards,
Todd Peterson
Main Topics
Browse All Topics
by: BigRatPosted on 2009-08-10 at 03:30:33ID: 25058542
Strictly speaking a chunked response is only allowed if the HTTP version is 1.1, so downgrading the version might help. You do this by posting the request using http/1.0. BUT some servers ignore this and reply with http/1.1. I have not seen however a chunked encoding in such a senario, so that might work.
Chunked encoding should be applied to CGI output, but sometimes it happens to files (read a block and chunk that out whilst waiting for the next block) and of course application servers, who pipe their responses back into the web server in blocks of 8K byte.
Chunked encoding is normally applied when the web server does not know the length of the data, as in CGI. Formerly the "end-of-data" marker was when the socket connection was closed. This meant that the client had to reestablish the connection for the next request to the same server (often for embedded script or images). The performance penalty is the time to reconnect.
Chunked "decoding" is easy to handle. One sees the transfer encoding in the response header and then expects after that (ie: after the newline) an HTTP header, which always (ie: must) includes a content-length header which gives the data length after the header (ie: after the newline). If the content-length is zero that denotes the end of stream (ie: after the newline) so you then know the complete length. You just need the mechanism to keep the (potentially large) data on tap until the end.
I'd personally implement the handling of chunked encoding, using Apache as a test server and a CGI script that outputs (say) 200KB of test data.