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

/me thumbs back through e-mails...

*ah* I see where this was coming from. Apologies.


On Thu, Jul 19, 2001 at 09:48:02PM -0400, christopher ferris wrote:
> 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/
> 

-- 
Mark Nottingham
http://www.mnot.net/

Received on Thursday, 19 July 2001 21:58:54 UTC