RE: Submission of HTTP Extension Framework (Mandatory)

From: Henrik Frystyk Nielsen (frystyk@w3.org)
Date: Mon, Aug 17 1998


Message-Id: <3.0.5.32.19980817100539.008cbc50@localhost>
Date: Mon, 17 Aug 1998 10:05:39 -0400
To: Yaron Goland <yarong@microsoft.com>, ietf-http-ext@w3.org
From: Henrik Frystyk Nielsen <frystyk@w3.org>
Subject: RE: Submission of HTTP Extension Framework (Mandatory)

At 21:41 8/11/98 -0700, Yaron Goland wrote:
>It is often the case that one needs to dumb down a 1.1 method to get through
>a 1.0 proxy. However, if a mandatory request doesn't include any c-* headers
>and is otherwise properly formatted why should the server be forced to
>reject it on the sole basis that it was received from a 1.0 client as
>required by rule 2 in section 5?

The reason is that HTTP/1.0 caches can not be trusted to handle mandatory
extension in such a way that it is positively save to assume that the
mandatory extension was handled by the origin server and that the result
doesn't get cached in unpredictable ways.

I am not looking for a solution that works in most cases or if the client
or server knows about each others capabilities - I am looking for a simple,
robust solution that works in all cases including the ones that involve the
existing deployed base.

>Many server side extension APIs do not provide support for sending 1xx
>responses. As such it would make implementing Mandatory harder by requiring
>a 102 response as specified by rule 5 in section 5. Why not just add a
>header to the 200 response such as "man-confirm:" which means "I did
>understand your mandatory header(s)"?

A single extension can determine whether its portion of the request can be
fulfilled but it does not necessarily know the overall outcome of the
result as this depends on the result of the other extensions as well.

It is therefore in fact an advantage that extensions do not have direct
access to this "yes, everything worked" mechanism but it has to be in the
server itself. Otherwise, we would simply be designing another "CGI method
trap" waiting to happen.

>If one receives a response to a DELETE with a mandatory header on it,
>treating the body as if it were application/octet-stream does not provide
>any help in determining what has actually happened as a result of the DELETE
>method. I believe section 6 needs to use more restrictive language of the
>form "The server MUST NOT send back mandatory headers on the response unless
>some form of negotiation has already occured which specifically allows it."

I would think SHOULD covers this: "You'd better do this unless you have a
really darn good reason not to". You can still rely on the status code so
that if you get 200 (and 102) then you know that it was deleted.

>If Keith stays true to form he is going to give you grief over making the
>URIs resolvable. He is going to ask you very pointed questions about how you
>deal with load when you have a whole bunch of people trying to resolve this
>URI. I think we are actually o.k. because resolution is not required for
>operation, rather it is a way for someone to figure out what some random
>mandatory extension they have never seen before is.
>
>Thus, since the URI is
>not really usable by an automated process, the over all load should be
>manageable.
>
I am aware of his concern but I am not sure how this differ from any other
popular resource on the Web - the hope is that the information is cachable
so that caches can take the heat out of the hot spot if people really like
to resolve it.

>Also, as much as I like to get referenced you never actually use [10]
>anywhere in the spec so it should be removed.

:)

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk