W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: Proposed resolution for the STATUS100 issue

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Thu, 17 Jul 97 15:03:22 MDT
Message-Id: <9707172203.AA15728@acetes.pa.dec.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3790
Maurizio Codogno <mau@beatles.cselt.it> writes:

     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 footer 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.
    This is present in RFC 2068 too, but it puzzles me. Why just the client
    and not the server? could someone explain it to me?

Maybe this is a little ambiguous.  It basically says that the
client should be watching to see if the server says something
like "HTTP/1.1 401 Unauthorized" while the client is sending
the request body.  This prevents the server from having to
consume a lot of unnecessary bytes, and prevents the Internet
from having to carry those bytes.  At the same time (if the
client is using "chunked") it avoids having to shut down
(and probably reopen) a persistent TCP connection, which is
an expensive operation.

The situation in the other direction is different.  Once the
server has started sending a response body, the client has no
way to send an "error status", except to close the TCP connection.
I guess we thought it was obvious that, if the client closes the
TCP connection, then the server should stop sending its response.
At some point in the past, we discussed defining a new HTTP
mechanism, perhaps together with TCP Urgent Pointer mechanism,
for the client to abort a request without closing the connection.
But this proposal did not meet with sufficient approval.

	If the request method is not idempotent, the
	client SHOULD NOT retry the request without user confirmation.
    I'd prefer a MUST NOT, especially in light of the following
    sentence.  As far as I can parse English language, it would mean
    that either the user agent knows for sure that it is safe to retry
    the request or it warns the user.

I've been given encouragement, by the working group, to avoid
using MUST when SHOULD is sufficient.  In this case, it seems
plausible that there may be some applications in which user
confirmation is hard to obtain, and the risks associated with
not finishing the request are less important than the risks
associated with non-idempotency.  At any rate, it might be hard
to rigorously define when a request is truly non-idempotent
(this is another issue that has recently come up).  So we should
not place mandatory restrictions on the implementors that might
be too strict.
    As for the exception for HTTP/1.1 only, am I correcting in
    inferring that the special case is just for interoperability with
    existing implementations, since in future versions no 100 status
    will be sent only if the client sends an Expect: header too?
Yes.  That's why it starts with "For compatibility with RFC 2068."

Received on Thursday, 17 July 1997 15:20:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC