Re: Proposal: 100-Continue optional under Client control

   Upon receiving a request which includes a content body and the
   "Expected: 100-Continue" request header, an HTTP/1.1 (or later)

I think "which includes a content body" is redundant here.  The
client should not be sending "Expected: 100-Continue" if it does
not intend to send a request body, right?  In fact, the specification
for "Expected: 100-Continue" perhaps should make this explicit.

   For compatibility with RFC 2068, an HTTP/1.1 (or later) server
   MAY send an intermediate 100 (Continue) status as described above
   to an HTTP/1.1 (but NOT later) client which didn't include the
   "Expected: 100-Continue" request header with 100 (Continue) status
   to minimize any client processing delays associated with an
   undeclared wait for 100 (Continue) status.

Change the "which" to a "that".  Also, perhaps this rather
lengthy sentence is too complex and repetitive?  How about:

   For compatibility with RFC 2068, a server MAY send an intermediate
   100 (Continue) status, as described above, in response to an
   HTTP/1.1 request that does not include the "Expected: 100-Continue"
   request header.  This exception, the purpose of which is to minimize
   any client processing delays associated with an undeclared wait for
   100 (Continue) status, applies only to HTTP/1.1 requests, and not to
   requests with any other HTTP-version value.

Koen writes, re "Upon receiving a request ...",
   Add: `from an HTTP/1.1 client'.  A 1.0 proxy will not strip off this
   header when relaying a request.
and also
    As the 100 mechanism is hop-to-hop, it looks like Expected must be a
    hop-to-hop header, so it must be added to the list in section 13.5.1,
    and the following text should be added to the header definition:
    
      The Expected header field is a hop-by-hop header field, and MUST be
      listed in a Connection header field, as described in section 14.10,
      when included in the request.
    
    As there are no 1.1 proxy implementations yet (I believe), we _could_
    get away with not requiring the Connection header.  This is an issue
    which needs to be discussed.
    
Actually, I believe that there are indeed HTTP/1.1 proxy
implementations that are nearly done, although I'm not sure if they
are deployed.  But it seems like a good idea to avoid too many
special cases, and so I would vote for making "Connection: expected"
mandatory if "Expected" appears in the request.

If so, then we don't need to add `from an HTTP/1.1 client', as Koen
suggests, as long as the next draft resolves the "CONNECTION2"
issues-list item (see http://www.w3.org/pub/WWW/Protocols/HTTP/Issues/
for a discussion).

-Jeff

Received on Wednesday, 2 July 1997 13:48:30 UTC