Hello all, I've stumbled upon an issue related maybe to my scarce knowledge of HTTP. I've setup a Jetty based "jax-ws" server application which I call from basex through the "http:send-request" function. Everything works neatly until the response document (plus the SOAP overhead) violates the 8192 bytes threshold in size. At that point the Xquery containing the request stops working. Investigating I've found out that the server starts sending back the data encoded as base64 instead of plain XML thus causing the failure of the following xquery expressions ( err:XPTY0019:Steps within a path expression must yield nodes; xs:base64Binary found. )
Sniffing around on my HTTP connection I've seen that the server automatically alters the HTTP response at the size of 8192 bytes sending the header "Transfer-Encoding: Chunked" instead of the usual two ("Content-Type:test/xml" and "Content-Length"). This problem doesn't occur if I use Firefox Poster or socat (yet to try other neutral tools). Is it because they're able to handle this aspect transparently?
What is the best solution to this? Is there a way (in the http request) to ask the server to avoid this change in behaviour? Do I need to handle this aspect at xquery application level?
I'd be rather happy about any suggestions. Thank you in advance. M.
Hi,
If this can be of any help, I faced similar problems for the EXPath HTTP Client implementation in Java. The problem (well, a feature, really) is that the transfer encoding "chunked" cuts down the response in several chunks, that the client has to reassemble. This is a feature of HTTP 1.1, so what you observe could be caused by either a client implementing HTTP 1.0 (which is pretty rare those days), or a client not supporting chunked encoding (if using external components, this might be as simple as enabling an option).
Hope that helps, regards,
One quick fix (wonder whether it's acceptable as definitive) is to set "override-media-type='application/xml" in expath http:request. In this way the XML representation of the document is returned independently of the size and/or transfer encoding. Is it correct like that?
M.
On 05/10/2013 04:00 PM, Marco Lettere wrote:
Hello all, I've stumbled upon an issue related maybe to my scarce knowledge of HTTP. I've setup a Jetty based "jax-ws" server application which I call from basex through the "http:send-request" function. Everything works neatly until the response document (plus the SOAP overhead) violates the 8192 bytes threshold in size. At that point the Xquery containing the request stops working. Investigating I've found out that the server starts sending back the data encoded as base64 instead of plain XML thus causing the failure of the following xquery expressions ( err:XPTY0019:Steps within a path expression must yield nodes; xs:base64Binary found. )
Sniffing around on my HTTP connection I've seen that the server automatically alters the HTTP response at the size of 8192 bytes sending the header "Transfer-Encoding: Chunked" instead of the usual two ("Content-Type:test/xml" and "Content-Length"). This problem doesn't occur if I use Firefox Poster or socat (yet to try other neutral tools). Is it because they're able to handle this aspect transparently?
What is the best solution to this? Is there a way (in the http request) to ask the server to avoid this change in behaviour? Do I need to handle this aspect at xquery application level?
I'd be rather happy about any suggestions. Thank you in advance. M. _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
basex-talk@mailman.uni-konstanz.de
-
Florent Georges -
Marco Lettere