W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2003

Re: expect header, clarification of status

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Tue, 28 Jan 2003 16:34:59 +0100
Cc: ietf-http-wg@w3.org
To: Scott Lawrence <lawrence@world.std.com>
Message-Id: <0F8D753E-32D6-11D7-A23E-00039384827E@greenbytes.de>


thanks for the quick reply. Comments below:

Am Dienstag, 28.01.03, um 15:38 Uhr (Europe/Berlin) schrieb Scott 

> Stefan Eissing <stefan.eissing@greenbytes.de> writes:
>> I'd like to get a clarification of the HTTP/1.1 Expect header (RFC
>> 2616, 14.20).  This feature is very useful to authoring clients,
>> however it currently causes interoperability problems far
>> outweighting the potential benefits.
> What problems?

If a client submits a request against a HTTP/1.1 server with:

Expect: greenbytes-super-feature-enabled

it has no way, in my understanding, to know if
1) the feature is supported
2) the feature is unsupported and the server complies only to 2068

That makes the Expect header useless for extension checks until the
protocol version is incremented some (far) time in the future.

>> There has been discussion on the http-wg mailing list ([1]) with the
>> statement by Roy that 2616 has broken compatibility to 2068.
>> There is however no clarification in the errata[2].
> The discussion you cited was during the development of RFC 2616; the
> errata only attempts to cover issues that arose after publication.
>> The conclusion I draw from the mentioned discussion is that
>> a) clients, talking to HTTP/1.1 servers, cannot rely on correct
>>      Expect header support, since they may be talking to 2068
>>      compliant servers.
>> b) Requests which have a body will cause the client to hang
>>     on a 2068 server. Unfortunately, using Expect together with
>>     PUT is one of the more attractive use cases.
> Section 8.2.3 lays out procedures for both client and server that I
> believe work for all the combinations of Expect header
> support/non-support.
I agree that 8.2.3 covers PUT with Expect: 100-continue, however the
offered solution gives a rather unsatisfying user experience in my
opinion.  There is no good heuristic to determine how long to wait
for the 100 Continue response. It does depend not so much on
network latency, but on server load, e.g. how long the server needs
to check whatever it wants to check before accepting the PUT.

"Expect" is a very useful feature, but in order to use it reliably, one
needs a way to discover its support for a certain resource. Don't
you agree?

Received on Tuesday, 28 January 2003 10:35:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:36 UTC