Re: 505 response a MUST?

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

Yeah, you are right -- I missed the change in semantics.

>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
>proxy:
>
>                               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.

Sounds better than I thought, but you still have a problem with an HTTP/1.0
proxy that forwards the M-method and does not strip the Connection header
field.  I assume the solution to this is to ignore/error any mandatory
extension received with HTTP/1.0 as the request HTTP-version.

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

I was referring to the basic OPTIONS * HTTP/1.1 connection probe.
The only thing the application cares about is that the next-hop
understands the meaning of mandatory and thus is capable of insisting
on its presence for the next hop beyond that.  Once the application
knows it is talking to a compliant server, it can cache this information
and safely use mandatory extensions from then on.

I still dislike the notion of prefixing method names.  On the whole,
I'd rather flush the idea and tokenize HTTP/2.x such that each primary
field can have an indicator as to the scope of its required-ness.
This is all too much complication and levels of indirection for a 
protocol that is supposed to remain simple.

....Roy

Received on Thursday, 5 March 1998 04:46:16 UTC