tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 39384] - Dreamweaver 8 Webdav times out and fails
Date Sun, 23 Apr 2006 15:41:54 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39384>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39384


rick@knowleses.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |RESOLVED
         Resolution|                            |INVALID




------- Additional Comments From rick@knowleses.org  2006-04-23 15:41 -------
Thanks ... that was a big help, and it revealed what I think is the bug.

Seems to be an RFC2616 interpretation thing.

The timeout occurs after the response to this request:

DELETE /intranet/staff/dav/MM_CASETEST4291/ HTTP/1.1
Authorization: Basic ***omitted***
User-Agent: Contribute/3.0
Host: localhost:8081
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

Note that this is an HTTP/1.1 request, with no Connection header, which I 
think the spec says (can't find it right now) can be assumed to be a keep-
alive request.

The response comes back as:

HTTP/1.1 204 No Content
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=02CBA58694E0F790389720E129151DF4; Path=/intranet
Date: Sun, 23 Apr 2006 14:40:56 GMT

Which then causes the server to hang. I think what happens is the client 
intreprets this as a keep-alive response, since there's no "connection:close" 
header, but because there's also no Content-length header it sits there 
waiting until the socket closes. 

I haven't checked resin yet, but Winstone sends connection headers every time 
(implicitly determining the right value if not set using the presence of 
response content-length header and req connection header) and therefore seems 
to avoid this situation.

Would I be right in assuming that Tomcat only has content-lengths on the >=400 
error codes, and so I have to set content-lengths manually on anything <400 ?

I set the content length to zero explicitly and the timeouts stopped - that 
seems to do nicely as a workaround.

Not sure if this is really a bug or not ... I'll leave it set as invalid, but 
maybe someone might want to add something in Tomcat similar to the auto-
correction thing I mentioned above. Or not - matter of opinion, just thought 
I'd document the reason for the problem I saw since it wasn't obvious and 
looked like a tomcat bug.

Thanks Mark for pointing out the tcpmon tool. Helped a lot.

Rick

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message