- From: Yaron Goland <yarong@microsoft.com>
- Date: Wed, 15 Apr 1998 14:23:01 -0700
- To: "'Henrik Frystyk Nielsen'" <frystyk@w3.org>, ietf-http-ext@w3.org
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
Received on Wednesday, 15 April 1998 17:23:15 UTC