RE: HTTP Ext Working Group Submission: Mandatory Extensions in HT TP

From: Henrik Frystyk Nielsen (
Date: Thu, Apr 09 1998

Message-Id: <>
Date: Fri, 10 Apr 1998 09:39:57 +0900
To: Yaron Goland <>,
From: Henrik Frystyk Nielsen <>
Subject: RE: HTTP Ext Working Group Submission: Mandatory Extensions in   HT TP

At 16:35 03/30/98 -0800, Yaron Goland wrote:
>It does not appear that the examples match the extension grammar. For
>example the first one should be: "rfc2068";;ns = SetCookie2

That is a bug - there should be only one. Added as an editorial issue.

>It is traditional to delineate URIs with "<" ">" not <">.

There are definitely many examples of both - I chose quotes as it is used
in Digest as well as the old URI header. I can't think of any HTTP header
field using "<" ">", can you? I have not added this as an issue.

>There is no reason given in the draft for why parameters should be included
>in the extension declaration. It appears to be to be sufficient to just give
>a list of URIs identifying various extensions along with prefixes. It is
>then up to each of the extension definitions to define how to pass in
>parameters, if any.

As an implementor, I would only use header fields to carry parameters if
they interacted with existing HTTP/1.1 features like caching, vary etc. If
not then I would certainly use parameters as they can be passed to the
extension asis.

I have added this as an issue and sent a mail to probe the consensus on the

>Note that while I have removed the explicit "-" I support requiring that
>there be a "-" in all names. So if you have: mandatory: <urn:mommy>01 means
>that any headers associated with <urn:mommy> MUST be of the form

Why not make it explicit then?
>I also think that the draft needs some language explaining that the prefixes
>are dynamically generated, one does not associate a particular prefix with a
>particular URI as a permanent mapping. Rather, when someone adds a mandatory
>header they need to be required to check the current message, see what
>prefixes if any are already in use, and pick a prefix that isn't already
>used in that particular message. We really need to warn people against hard
>coding a prefix.

Good point - I have added this.

>If we are going to have mandatory response headers then it seems to me that
>the proper client behavior upon receiving a mandatory response it does not
>understand is to treat the response as a 500 response which contains no
>headers or body. In fact we should probably introduce 3xx, 4xx, and 5xx
>responses for use with Mandatory so that the server can choose how the
>client will treat a mandatory response in the case that the client does not
>support mandatory in general or one of the mandatory extensions in

Do I understand you as that every response containing a Mandatory extension
(regardless of it being requested by the client or not) should use a
special status code within each class, say x99, for example? This is an
interesting idea but it does have a couple of (potentially unexpected)

1) It doesn't allow extending existing status codes like 206 (Partial
Content) response code with a mandatory extension.

2) A response extension may be hop-by-hop and hence removed on the way to
the client. The message is therefore not extended anymore and should be
treated as a normal message. This causes a problem in existing 1.1 proxies
that would remove the extension (because it is declared as a Connection
directive) but not change the status code so it would still say 299
although the message is not extended anymore.

The question in general is what the relationship is between an extension
and the rest of the message. As far as I can see, there are two different
possible policies for handling an extended message:

a) Strip off the extension, deal with it, and treat the rest as a basic
HTTP/1.1 message with either an already defined method or an already
defined status code.

b) Execute the extension When processing leave the definition of what to do
with the message completely to the extension.

The current policy is a) - Ted had a similar note on the M- method token
prefix, so it is obvious that the policy is not made clear. However, I
think that it is worth being explicit about how to handle an extended message.

This includes answering the questions:

i) What happens if an application wants to introduce a new method that
doesn't have anything to do with existing methods?

ii) What happens if an application understands the extension but not the
base method, M-COPY, for example.

I have added this as an issue.

>The second and third paragraphs in section 7 really confuse me. Could you
>please clarify?

It is based on the same mechanism that authentication header fields use in
order to avoid unnecessary repetition of requests. I have added a point for

>Also the document should explain the relationship between mandatory and the
>expect header. (Thanks Paul)

Yes - new issue.

>Reference 7 is Y.Y. Goland! Y. Goland is my father. =)



Henrik Frystyk Nielsen,
World Wide Web Consortium