W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1998

Minor editorial (?) problem(s) for Expect (section 14.47)

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Mon, 05 Jan 98 18:46:50 PST
Message-Id: <9801060246.AA22244@acetes.pa.dec.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5067
Section 14.47 of draft-ietf-http-v11-spec-rev-01 defines the Expect
mechanism, but does not state whether token-matching should be case

E.g., if the client sends
	Expect: 100-ConTinUe
what should the server respond with?  The current specification
is ambiguous.

My suggestion: comparisons for unquoted tokens should be case-insensitive;
comparisons for quoted strings should be case-sensitive.

Also, although this is implicit in the design, I think the text
should note that this is a hop-by-hop mechanism; i.e., "server"
means "origin server or proxy", not just "origin server".

Suggested wording (add just before 14.47.1)

	Comparison of expectation values is case-insensitive for
	unquoted tokens (including the 100-continue token), and is
	case-sensitive for quoted-string expectation-extensions.

	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.


P.S.: It may also be a bug that we didn't define an end-to-end version
of Expect.  The current specification, at least, has no way to mark an
expectation as end-to-end rather than hop-by-hop.  I hestitate to open
another can o' worms, though.
Received on Monday, 5 January 1998 18:48:33 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC