Re: Large content size value

Scott Lawrence wrote:
> 
> Yes we have.   For a large body in a request, the server can return an
> error; the client is required to abort sending the body if an error is
> received.  For a large body in a response, it's not lovely, but it's well
> understood - the client just closes the connection.  Since there is no
> 3-way handshake, that's the best that can be done.

+1, this is well understood and reasonably well documented.  There is no
need, and significant arguments against defining a range for DIGIT*1 as
anything less than infinity, and it is up to the implementor to decide
what it can parse, what it cannot parse yet still work around, or what it
simply cannot work around.  Disconnecting, in the third case, is the only
remaining alternative...

<snip>
8.1.4 Practical Considerations
[...]
   A client, server, or proxy MAY close the transport connection at any
   time. For example, a client might have started to send a new request
   at the same time that the server has decided to close the "idle"
   connection. From the server's point of view, the connection is being
   closed while it was idle, but from the client's point of view, a
   request is in progress.

   This means that clients, servers, and proxies MUST be able to recover
   from asynchronous close events. Client software SHOULD reopen the
   transport connection and retransmit the aborted sequence of requests
   without user interaction so long as the request sequence is
   idempotent (see section 9.1.2). Non-idempotent methods or sequences
   MUST NOT be automatically retried, although user agents MAY offer a
   human operator the choice of retrying the request(s). Confirmation by
   user-agent software with semantic understanding of the application
   MAY substitute for user confirmation. The automatic retry SHOULD NOT
   be repeated if the second sequence of requests fails.

   Servers SHOULD always respond to at least one request per connection,
   if at all possible. Servers SHOULD NOT close a connection in the
   middle of transmitting a response, unless a network or client failure
   is suspected.

   Clients that use persistent connections SHOULD limit the number of
   simultaneous connections that they maintain to a given server. A
   single-user client SHOULD NOT maintain more than 2 connections with
   any server or proxy. A proxy SHOULD use up to 2*N connections to
   another server or proxy, where N is the number of simultaneously
   active users. These guidelines are intended to improve HTTP response
   times and avoid congestion.

[...]

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.

[...]

8.2.4 Client Behavior if Server Prematurely Closes Connection
</snip>

(Note: no corresponding description of "Server Behavior if Client Prematurely
Closes Connection").

I'm searching for any evidence of a behavioral requirement for Server Response
that the Client "does not understand" and I'm coming up empty.

So (s. 8.1.4 Practical Considerations) "A client, server, or proxy MAY close
the transport connection at any time" is the final word.

Unless I'm mistaken, if the client is unwilling to handle the server's response,
the client MUST (gracefully? abruptly?) close the transport connection.

And that's the beginning and end of the story for ALL RESPONSES AND RESPONSE
HEADERS THAT THE CLIENT IS UNWILLING/UNABLE TO HANDLE. (*)

(*) distinct from s7.1 "Unrecognized header fields SHOULD be ignored by the
recipient"

Of course, other means to avoid the condition in the first place; initially
issuing a HEAD request against the desired resource can avoid this quandary
but that's the choice of the user-agent's implementor, and doesn't avoid
the situation for C-E: chunked.

There is no need to proceed with this discussion.  There's an opportunity
to expand upon 8.1.4 offering that the client may disconnect with example
reasons; or an opportunity to expand upon 8.2 for the converse of 8.2.4.
The participants here, and the host of implementors to date, seem to have
no problem understanding this from the existing spec.

As 8.1.4 says, for whatever reason.  You don't need one.  If you aren't
going to use the response, disconnect already.  It's up to the implementor
not to ignore overflows of ANY response header, and that includes DIGIT*1.

Can we please move on?

Received on Friday, 5 January 2007 22:32:49 UTC