W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

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

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 19 Jul 2001 18:40:15 -0700
To: Mark Baker <distobj@acm.org>
Cc: christopher ferris <chris.ferris@east.sun.com>, xml-dist-app@w3.org
Message-ID: <20010719184011.A1490@mnot.net>

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

  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
  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

  <TITLE>417 Expectation Failed</TITLE>
  <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
  but we only allow the 100-continue expectation.
  Connection closed by foreign host.

There is no way to change this behaviour, AFAIK, without fiddling
with Apache's internals (module, etc.)

Mark Nottingham
Received on Thursday, 19 July 2001 21:40:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:14 UTC