Jason Hunter wrote:
>
> If you think about how HTTP works, the client makes a request, then the
> server sends a response. The client doesn't expect or look for the
> response until the request has completed. So if the server decided the
> request is too large to process, what's going to happen? Either the
> server "eats" the request to generate a proper error message thus
> wasting bandwidth, or the server "hangs up" on the client while the
> client is sending the request. You're seeing the latter behavior.
>
Ok, I'm going for the most pedantic post of the year
award here, but doesn't 1.1 require (well, SHOULD
anyway) the client to monitor the connection while a
request message body is being sent?
rfc2616:
8.2.2 Monitoring Connections for Error Status Messages
An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
the network connection for an error status while it is transmitting
the request. If the client sees an error status, it SHOULD
immediately cease transmitting the body. If the body is being sent
using a "chunked" encoding (section 3.6), a zero length chunk and
empty trailer MAY be used to prematurely mark the end of the message.
If the body was preceded by a Content-Length header, the client MUST
close the connection.
I'm pretty sure, from its use in other parts of the spec,
that "error status" refers to an HTTP error response,
rather than a network close.
And yes, I realize that in real life most browsers don't
work this way, so everyone not interested in spec trivia
probably should just do what Jason Hunter says :-)
-cks
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
