Re: expect header, clarification of status

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 Tuesday, 28 January 2003 11:57:08 UTC