Re: expect header, clarification of status

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.

//Stefan

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

> 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