Re: another approach to status codes, etc. in HTTP binding

Mark N,

I'm quite sure that Mark B was using Expect as an analogy
not as a proposed approach to handling mustUnderstand by
leveraging HTTP semantics in the binding.

Cheers,

Chris

Mark Nottingham wrote:
> 
> On Thu, Jul 19, 2001 at 09:17:58PM -0400, Mark Baker wrote:
> > >> How does Expect help in this situation?
> >
> > Expect has basically identical semantics to mustUnderstand.  The
> > only difference being that mustUnderstand is explicitly associated
> > with a header block, whereas Expect isn't associated with anything
> > in particular.
> 
> Aha. This is a perfect illustration of the dangers of mixing up SOAP
> semantics and HTTP semantics.
> 
> Expect is a directive that was hand-tailored for the case that a
> client might have a big POST that they weren't sure that a server
> could support; in conjunction with a 100 Continute response, it
> allows for this check.
> 
> Although Expect does permit expectation-extensions, they would be
> extensions to HTTP itself; the server is required to understand them
> to process them. They have nothing to do with the semantic of the
> entity body's content, but rather the HTTP protocol mechanism.
> 
> Furthermore, the processing of Expect is hop-by-hop; HTTP
> intermediaries must understand the expectation to process it. From
> 14.20:
> 
>   The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
>   return a 417 (Expectation Failed) status if it receives a request
>   with an expectation that it cannot meet. However, the Expect
>   request-header itself is end-to-end; it MUST be forwarded if the
>   request is forwarded.
> 
> It may be helpful to understand that when RFC2616 uses 'server', it
> can mean ANY device that accepts HTTP connections, including proxies,
> gateways (surrogates), not just origin servers.
> 
> All of this means that if we use Expect and 417 to indicate mU
> conditions and faults, we'll get serious interoperability issues with
> both server and intermediary implementations. For example,
> 
>   1-143:~> telnet www.mnot.net 80
>   Trying 64.170.196.246...
>   Connected to www.mnot.net.
>   Escape character is '^]'.
>   GET / HTTP/1.0
>   Expect: foo
> 
>   HTTP/1.1 417 Expectation Failed
>   Date: Fri, 20 Jul 2001 01:25:28 GMT
>   Server: Apache/1.3.12
>   Connection: close
>   Content-Type: text/html; charset=iso-8859-1
> 
>   <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
>   <HTML><HEAD>
>   <TITLE>417 Expectation Failed</TITLE>
>   </HEAD><BODY>
>   <H1>Expectation Failed</H1>
>   The expectation given in the Expect request-header
>   field could not be met by this server.<P>
>   The client sent<PRE>
>       Expect: foo
>   </PRE>
>   but we only allow the 100-continue expectation.
>   </BODY></HTML>
>   Connection closed by foreign host.
> 
> There is no way to change this behaviour, AFAIK, without fiddling
> with Apache's internals (module, etc.)
> 
> --
> Mark Nottingham
> http://www.mnot.net/

Received on Thursday, 19 July 2001 21:48:05 UTC