Re: Proposed resolution for the STATUS100 issue

% From: Jeffrey Mogul <>

% 8.2.2 Monitoring connections for error status messages
%    An HTTP/1.1 (or later) client sending a message-body [...]

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?

%    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.

All the rest is fine for me, especially new error 419 and header Expect:

In particular, the two SHOULD NOT Scott objects to,

JM>    o  An origin server SHOULD NOT send a 100 (Continue) response if
JM>       the request message does not include an "Expect" request-header
JM>       field with the "100-continue" expectation, and MUST NOT send a
JM>       100 (Continue) response if such a request comes from an HTTP/1.0
JM>       (or earlier) client.

JM>    o  An origin server SHOULD NOT send a 100 (Continue) response if
JM>       has already received some or all of the request body for the
JM>       corresponding request.

are ok for me. 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?

ciao, .mau.

Received on Thursday, 17 July 1997 08:10:36 UTC