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

From: Yaron Goland (yarong@microsoft.com)
Date: Wed, Apr 15 1998


Message-ID: <3FF8121C9B6DD111812100805F31FC0D029711D1@red-msg-59.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: "'Henrik Frystyk Nielsen'" <frystyk@w3.org>, ietf-http-ext@w3.org
Date: Wed, 15 Apr 1998 14:23:01 -0700
Subject: RE: HTTP Ext Working Group Submission: Mandatory Extensions in HT 	 TP

My understanding is that a mandatory header on a response means "If you
don't understand this header you can't understand this response." But what
does that mean for the client? The poor client executed a GET and got back a
200 request with a mandatory header. Is that a 5xx error? A 4xx error?

I think mandatory headers on responses should just be banned. Mandatory
should be a request only header.

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

If a mandatory header is used and the recipient doesn't understand it then
the 206 will be ignored anyway. If the client does understand the mandatory
extension then one assumes the extension will also make clear what the
original error code was.

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

A perfect example of why mandatory MUST NOT be used in responses, you have
no clue if any intervening proxies will properly honor it.

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

That is already the default behavior for HTTP, no need for a mandatory
header in order to implement that. BTW this is the part where you get
slapped on the hand for combining prefix naming with mandatory. I suspect
what you really want from the mandatory response header is prefixing, not
the mandatory functionality.

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

This assumes the client understands the extension. If the header is to earn
its name, mandatory, then not understanding its contents must cause a
failure scenario. I'm trying to get at what this failure scenario is.

BTW Ted's comments on making it clear that mandatory needs to go first
because of the prefix naming issue is right on.

		Yaron