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: Wed, 29 Jan 2003 12:11:44 +0100
Cc: ietf-http-wg@w3.org
To: Alex Rousskov <rousskov@measurement-factory.com>
Message-Id: <734C78F0-337A-11D7-A23E-00039384827E@greenbytes.de>

Thanks Alex for the excellent summary. I hadn't though yet about
the intermediates problem regarding Expect.

The way forward is probably a mix of your a) and b) scenarios. In case
of methods like OPTIONS and others (and WebDAV has quite a lot) most
servers nowadays have good support. Apple has support calls with
HTTP proxies regarding their WebDAV iMac service. They have real
interest ot solve it. So, I think, the method "problem" will go away
rather sooner than later.

Chunked requests are still a problem. Even when servers are ok, there
are a still servlet engines which screw up. At least we got Tomcat to
support it since 3.1.

I am currently trying to confirm that proper handling of Expect is *not*
possible with the current Java Servlet API. That would be real bad.

If this is indeed the case, we need to work on another solution in
WebDAV for the PUT/continue which works end-to-end. Currently,
a PATCH kind of method looks attractive. The discovery of
supported methods works quite well with WebDAV/OPTIONS.


Am Dienstag, 28.01.03, um 17:57 Uhr (Europe/Berlin) schrieb Alex 

> On Tue, 28 Jan 2003, Stefan Eissing wrote:
>> 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.
> True. A quick look at our test results shows that our of 6 HTTP
> proxies, 5 violate at least one Expect-related test case, and some
> violate most of them. I suspect that origin server support is similar.
> Moreover, since Expect mechanism is hop-by-hop, you have to have
> compliance all the way through to the origin server.
> Furthermore, many intermediaries do not forward 1xx responses to
> clients or forward the first 1xx response and then close the
> connection. This breaks compatibility further.
>> 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.
> Clients, in general, do not know the version of the "server" in this
> context because the mechanism is hop-by-hop and you may have a mix of
> HTTP/1.1 and 1.0 intermediaries (including things like surrogates).
>> 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.
> I think it is OK to assume that all servers out there are either
> HTTP/1.0 or (2616-based) HTTP/1.1. This is not true in reality, but
> the fact that many servers violate RFC 2616 they are based on, makes
> the 2616/2068 distinction unimportant. Hopefully, we can increase the
> number of RFC 2616 compliant agents in the foreseeable future. We are
> successfully working with many open and proprietary projects on that.
> In other words, forget about 2068, but do not assume that every
> HTTP/1.1 server complies with the 2616 specs it was built on.
>> Assuming these conclusions are correct, do you have any opinion
>> which direction WebDAV should take in this matter? It is highly
>> desirable to offer something like Execpt: 100-continue to a client,
>> before it tries PUTting its 100MB file onto a server.
>> As far as I can see, announcing support for Expect in a OPTIONS
>> response seems to be one way to move forward.
> It is kind of ironic that one would put support for a MUST-level
> feature into OPTIONS. An even bigger problem is that OPTIONS (and
> Max-Forwards) are not well supported either.
>> Are there other ideas how to make Except usable to clients?
> I think you have to make a choice:
> 	a) Rely on (in specs) and push for (in public forums)
> 	  RFC 2616 compliance. Implementations will run into
> 	  real-life compatibility problems. In my experience,
> 	  the popularity of WebDAV will force the majority
> 	  of implementations to become compliant (in
> 	  relevant areas) relatively soon after WebDAV users
> 	  start to bombard server/proxy support teams with bug
> 	  reports. WebDAV already relies on things that do not work
> 	  perfectly in real world, such as extension request
> 	  methods (IIRC), and proxies/servers are improving
> 	  their support for that.
> 	b) Use just the basic RFC 2616 functionality. Never
> 	  use Expect/OPTIONs/chunked requests unless there
> 	  is a safe and clear way to back off to something
> 	  simpler. For example, you can send 100MB objects
> 	  in small chunks (one chunk per HTTP exchange) and
> 	  provide an extension header identifying those
> 	  chunks so that a server that supports WebDAV would
> 	  be able to assemble a complete object while
> 	  all intermediaries would be happy to pass a simple
> 	  PUT trough. Alternatively, you can invent an
> 	  XOPTIONS/XEXPECT pair with end-to-end semantics and
> 	  sent XOPTIONS request before uploading 100MB object.
> 	  All this introduces extra bytes on the wire.
> 	  This also complicates your specs and implementations,
> 	  but it makes immediate deployment more smooth.
> Some people will call option (a) the "Right Thing To Do". Some people
> will argue that option (b) is the only way it can be done.
> HTH,
> Alex.
> -- 
>                             | HTTP performance - Web Polygraph 
> benchmark
> www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
>                             | all of the above - PolyBox appliance
Received on Wednesday, 29 January 2003 06:12:03 UTC

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