- From: Henrik Frystyk Nielsen <frystyk@w3.org>
- Date: Tue, 20 Jan 1998 18:12:29 -0500
- To: "Scott Lawrence" <lawrence@agranat.com>, Paul Leach <paulle@microsoft.com>
- Cc: ietf-http-ext@w3.org
At 15:43 1/20/98 -0500, Scott Lawrence wrote: > If I don't understand the extention it doesn't matter whether or not > I know what headers go with it - I return an error anyway. This causes a problem _if_ an application _thinks_ it knows a header field but this header field in fact has been used by another extension with completely different semantics. This is an unavoidable problem when multiple extensions share a single, global header field space and no central registry can hinder this. The alternative is to pass all extension information as parameters: M-GET / HTTP/1.1 Host: foobar Man: "http://screwball.org/skidoo.html"; Skidoo=abc, "http://nutcase.org/skidoo.html"; Skidoo=def which avoids the problem altogether. The spec already says that all unknown parameters should be passed to the extension. > That is my point, and I'll restate it as a question: > > Is the goal of the draft to specify how to require the use of a > particular extention, or is it to specify how to do dynamically > loaded extentions? It is to allow multiple extensions to coexist in a distributed environment without knowing about each other. How an application gets to know about the semantics of an extension is entirely up to the application - downloading a module is only one way. >PL> 23-Skidoo and 65-SKidoo are _not_ the same header, so they shouldn't be >PL> folded. > > They are for CGI purposes after the prefixes have been removed (or > are we going to require that CGIs also understand prefixes?). There is no reason why prefixes should ever have to be passed outside the Mandatory extension mechanism. If the CGI script gets the header fields through the Mandatory filter then this can easily strip off the prefixes. Henrik -- Henrik Frystyk Nielsen, World Wide Web Consortium http://www.w3.org/People/Frystyk
Received on Tuesday, 20 January 1998 18:13:39 UTC