Re: 10.4 Client Error 4xx and 10.5 Server Error

    The second sentence of 10.4, and a similar sentence in 10.5, 
    applying to all 4xx and errors says:
    
    "If the client has not completed the request when a 4xx code is
    received, it SHOULD immediately cease sending data and close the
    connection."
    
    This broad a statement, across all 4xx and 5xx errors, seems draconian,
    but I've not studied all the details of persistent connections.

I think it's probably too stringent.  (Fortunately, it's a SHOULD,
not a MUST.)

For example, it's probably not necessary for the client to close
the connection upon receipt of a 401 (Unauthorized) response, since
the definition of 401 says that the response MUST contain a challenge,
and so presumably the client is expected to retry its request with
a "suitable Authorization header field."  Why not simply use the
same persistent connection?

Anyway, I'd suggest changing that sentence to something like
    
    If the client has not completely transmitted a request when a 4xx
    code is received in response to that request, it SHOULD immediately
    cease sending data and close the connection, unless the code (e.g.,
    401) encourages the client to make another request and the client
    does not have to send much more data to terminate the request in a
    syntactically valid manner.

After all, we don't have a way to mark the premature end of a request
once content-length has been sent.  A request sent using a Chunked
encoding could, however, be terminated early simply by sending
the zero-sized chunk.  So I think the right rule of thumb for the
client is "if you can terminate the request cleanly without sending
more than about 1 more data packet, then don't close the connection."
If it's going to take several round-trips to clean up, however, it's
probably more efficient to close and reopen the transport connection.
    
    I'm also bothered by the words "the request"; when piplelining, which
    request?  Shouldn't it at least say something like "the request that
    generated the error"?

Since we don't allow reordering of responses on a pipelined connection,
it should be unambiguous.  I tried to make this more explicit in
my suggested wording (above).

-Jeff

Received on Monday, 3 June 1996 15:37:48 UTC