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

Re: 505 response a MUST?

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Mon, 02 Mar 1998 14:41:42 -0500
Message-Id: <>
To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Cc: HTTP Working Group <http-wg@cuckoo.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5422
At 22:44 3/1/98 -0800, Roy T. Fielding wrote:

>But Henrik, both are demonstrably false.  The "method name fix" does not work
>with existing proxies, since many existing proxies will forward an unknown
>method name even if they do not understand it.


I think we have different ideas of what Mandatory is supposed to do: The
semantics of a mandatory extension as written in the current draft [1] is
that the "ultimate recipient" is required to deal with it, not necessarily
any intermediate proxy. Therefore, tunnelling is less of a problem for at
least end-to-end mandatory extensions. Hop-by-hop extensions can be dealt
with as described below.

In both situations the correct answer is "some do and some don't" leaving
the following questions:

	1) Do we want a "right answer" (do or don't) for new apps?
	2) Can Mandatory work with both the do's and the don'ts?

For Mandatory, 1) is strictly a question of esthetics and whether we want
to integrate something like Mandatory into new versions of HTTP or not. New
applications (and new HTTP revisions) that do not do Mandatory by
definition fall into the 2) category and hence it should be possible to
live without it (although acceptable, I do not particularly like this).

The more interesting (essential, in fact) question is whether Mandatory can
be made to work with both the do's and the don'ts. This should be possible
to check out by looking at the possible outcomes from a non-mandatory-aware

                               HTTP Proxy Server
     Scope   |          Hop-by-hop          |        End-to-end
    Strength | Optional   |   Required      | Optional   |   Required
 Intended    | Strip      | 501 or tunnel   | Forward    | 501 or tunnel
 Behavior    | extension  | extension       | extension  | extension
             |            |                 |            | 
 Unintended  | Forward    | Forward         | Strip      | Strip
 Behavior    | extension  | extension       | extension  | extension

Optional hop-by-hop extensions do not require any method name change, so
this only involves the Connection header. HTTP/1.1 already have
restrictions on how to deal with the interactions between Connection
headers and HTTP/1.0 applications and they apply to Mandatory as well.

Mandatory hop-by-hop extensions do require a method name change as well as
the Connection header field. If the request unintentionally is forwarded
instead of properly processed or tunnelled then the M- method name prefix
would be all that would be left in the forwarded request forcing the origin
server to respond with a 501.

If all the mandatory extension headers of an end-to-end extension were
stripped by a proxy then this would be the same situation with a lonely M-
method name that can not be correctly dealt with by any origin server.

>Requiring that servers
>puke on each new major version number does not work because HTTP/1.x
>servers do not puke on each new major version number, nor should they
>since the decision of when and why to bump the major version number is
>essentially a political one.
>In order for Mandatory to work, you must find a mechanism that works with
>existing systems, and the only one that works right now is to probe the
>connection with an OPTIONS request.

No, the OPTIONS method has exactly the same problems as any M- method for
all the existing proxies that pass through unknown methods.

However, the main reason why OPTIONS can't substitute the method name hack
is that an application has no guarantee that two requests will travel over
the same message path, nor that they will be handled by the same instance
of the origin server, nor that the information contained in an OPTIONS
response is still valid for subsequent requests.

The information returned in a OPTIONS response can be informational only
and hence is complementary to the Mandatory spec.

>We can't standardize on something
>that is based on a prerequisite contrary to reality.

I don't think we disagree on that but I also think that the Mandatory spec
is sound wrt weird, real-life proxies.


PS: I think this discussion is more appropriate on the
<ietf-http-ext@w3.org>  mailing list, so I cc that list. Please continue


Henrik Frystyk Nielsen,
World Wide Web Consortium
Received on Monday, 2 March 1998 11:44:01 UTC

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