[EMAIL PROTECTED] wrote:
We finally got Slide-2.x deployed successfully and were able to test with
Weblogic 6.1 SP4 on Win2k, here are some results:

Issue with Weblogic Chunked Responses:
- Weblogic sends chunked responses using:  "Transfer-Encoding: Chunked" for
methods like PROPFIND.
- The org.apache.commons.httpclient.ResponseInputStream was indicating the
reponse was NOT chunked, causing parsing errors.
- The problem was in the constructor where it searches for chunked
responses using:
            transferEncoding.getValue().indexOf("chunked")
- This would return false because it is case sensitive so we changed it to
be case insensitive.
- Not sure if this change would still be required when Slide migrates to
the new HttpClient.
- Does the Http 1.1 Specification discusss case of the Header attribute
values??
That's a bug, thanks for finding it. Care to send us a patch (unified diff format, please)? HTTP/1.1 (RFC2616) section 3.5, paragraph 2: " All content-coding values are case-insensitive.".


The infamous PUT problem:
- When we PUT a file against WL 6.1 SP4, it still adds the encoding bytes
to the file

Questions about this:
- Is it the responsibility of the App Server to assemble the chunked
request as its being processed by the webapp??
Yes, it is.

- In other words, while the webapp is calling the getInputStream() on the
HttpServletRequest object??
- It just seems odd to me that this behavior is still persistent in SP4 of
a commercial product.
- Wouldn't this also mean that putting any file against the server would
get corrupted, not just the ones using Slide??
Any put using a chunked transfer encoding, yes. Using chunked transfer encoding for a request body isn't all that common, which is probably why this problem has persisted for so long (I had to fix a similar problem in tomcat 4.0 and again in 4.1 - this particular problem is surprisingly common

Our solution to the PUT problem:
- We implemented a server-side RequestInputStream and hooked it into
org.apache.slide.webdav.method.PutMethod
- We based this class on the client side ResponseInputStream in the
org.apache.commons.httpclient package
- We only use this class when we are running in WL 6.1 environment.
- We are still testing this fix but it appears to work so far.

Yeah, that's the sensible hack for working around that particular bug. Painful that you have to do it, of course.

Mike



--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to