[EMAIL PROTECTED] wrote:
Seeing (if you're looking at the raw over-the-wire HTTP response) those hex numbers is perfectly normal - those are part of the HTTP/1.1 chunking mechanism. On the server side, weblogic (as far as I know) creates those correctly, and the slide client reads them fine, so this shouldn't be a problem.Michael -Thanks so much for the timely response. I did see a thread a few weeks ago dealing with the junk characters during a PUT method issued against a Weblogic server. We are also seeing junk characters in responses of methods like PROPFIND, etc.... It seems to wrap the XML portion of the response with those same 3 and 4 digit hexadecimal numbers, which causes the Slide client some issues parsing the response (invalid XML). I was just wondering if anyone had successfully overcome all these little issues in Weblogic and got everything to work for the Slide-2.x codebase.
The problem comes when weblogic _receives_ a chunked request (which the slide client does produce. Many other clients probably do as well). It doesn't (due to a bug) read those correctly.
If you want to make slide work with weblogic despite this bug, there are a couple of things you could do (both are nasty hacks, and won't go into the main slide codebase).
1) Make the slide client not produce chunked requests. This will probably require buffering all the requests, so that a proper content-length header can be set, before sending the entire body without chunking. Shouldn't be too hard, but it's inefficient and won't help if you use any other clients that used chunked bodies.
2) Implement a servlet filter (and configure your webapp so that the filter is applied to the slide webdav servlet (and only that servlet), and make this servlet filter strip out the chunks (as well as the transfer-encoding: chunked header), so that by the time the webdav servlet sees the request, there's no sign of chunking. Be careful to only do this on requests to the servlet, not on responses from it. (This is where the weblogic bug is - it should be doing this, though not as a servlet filter, internally. It doesn't).
Michael
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
