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=31567>. 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=31567 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|blocker |enhancement Status|RESOLVED |REOPENED Resolution|INVALID | ------- Additional Comments From [EMAIL PROTECTED] 2005-02-03 17:02 ------- (In reply to comment #10) > > Can you please be more specific? What is wrong with the requests from the > > client? I can't tell if you have issue with data on the original or second > > request. > The orignal request. See RFC 2616 Section 8.2.3. > And, like Remy has said many times, this is invalid, so please stop wasting > everybody's time by reopening it. Hello folks, I'm having a problem similar to the piotr's one, but in a different context and concluded that the .net client does not have a bad behavior. Tomcat on the other side isn't behaving improperly, but could behave better. Here goes: On section 8.2.3 it states that a client does not need to wait indefinitively for a server to respond with an 100 Continue message before starting to send it's body content of a request with the expect header. The M$ does it, and I believe they do it for performance reasons (perhaps it's a: "we ask if we can, but let's starting sending while the response does not come back, we win time if the response is positive") while the spec says that it's ok to do that because of the compatibility with older implementations of HTTP. It also says that if the server starts to receive data from the client, he may ommit the 100 continue response message. Plus, it also says that, when the server refuses an request with the expect header, and already received data it MAY close the transport connection or it MAY to continue read and then discard the rest of the request. So, TOMCAT doesn't do either, but does half of the second MAY. Now, if 505 error occurs because of the data on input stream (the body of the previous request) that is understood as a new request, I believe that the SPEC is not very clear about the issue and perhaps it should be more 'rule- enforcing'. In that case I believe that the server SHOULD close the transport connection OR it SHOULD read all data AND then discard it. Since TOMCAT already reads it (i supose it is the origin of the 505 error), I believe it also should discard it. That would be great for me, since I wouldn't need to add a if-command in my code :) Best regards, Miguel Figueiredo -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
