You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-user@jakarta.apache.org by "Sutton, Ndele" <Nd...@citadelgroup.com> on 2002/09/03 20:50:41 UTC

RE: Client problem with PutMethod on WebLogic 6.1 sp3

the problem was resolved by unchecking the "Enable Keepalives" check box.
this option determines whether the HTTP responses generated by WL contain
HTTP 1.0-compliant Keep-Alive headers.  somewhere in the interaction of
client and server, this caused the errors described below.

this wasn't a problem with cadaver when keep-alives were enabled.

> -----Original Message-----
> From: Sutton, Ndele [mailto:Ndele.Sutton@citadelgroup.com]
> Sent: Thursday, August 29, 2002 4:47 PM
> To: 'slide-user@jakarta.apache.org'
> Subject: Client problem with PutMethod on WebLogic 6.1 sp3
> 
> 
> i'm having some issues with the PutMethod and WL 6.1.  it 
> appears that the
> PutMethod leaves WL in a bad state, and the next request, 
> without empty
> bodies, from the same client (e.g. PROPFIND) results in a 
> "400 Bad Request"
> response.  the subsequent request gets split into two parts, 
> header and
> body, and both parts get sent to the server.  there are 
> actually two "400
> Bad Request" responses generated by a PropFindMehtod: one is 
> generated in
> WebdavMethod.parseRequestContent (line 486) when it tries to 
> parse an empty
> requestBody, and the other occurs when 
> WebdavServlet.createWebdavMethod()
> tries to find a matching method for "<?xml".  after the bad 
> response, the
> client and/or server return to normal operation.
>  
> there are a couple of things that i have found that remedy 
> this behavior:
> 1. if another client issues a request after the first client 
> has performed
> the put, but before the propfind
> 2. the connection is aborted/times out after the put and and 
> before the
> propfind
>  
> i have noticed that this is not a problem with cadaver.  it may have
> something to do with the ServletRequest's session id.  
> cadaver gets a new
> session id for every request, while the slide client holds on to it's
> session id using a cookie.
>  
> questions
> ==================
> 1. has anyone else experienced/resolved this problem with WL 
> and the slide
> client?
> 2. is there any way to turn off the cookies in either WL or
> slide/HttpClient?
>  
>  
> thanks,
>  
> ndele
> 

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>