DO NOT REPLY [Bug 31567] - 505 request error from .NET client

[bu...@apache.org]

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


mfigueiredo@maisis.pt changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |enhancement
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |




------- Additional Comments From mfigueiredo@maisis.pt  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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org