- From: Scott Lawrence <lawrence@agranat.com>
- Date: Tue, 20 Jan 1998 14:41:19 -0500
- To: Paul Leach <paulle@microsoft.com>
- cc: Rohit Khare <rohit@bordeaux.ics.uci.edu>, frystyk@w3.org, ietf-http-ext@w3.org
>>>>> "PL" == Paul Leach <paulle@microsoft.com> writes:
PL> Numeric perfixes aren't to allow multiple instances of the _same_ extension
PL> in one message -- they are to guard against the possibility (to use your
PL> example) that two independent parties design an extension, and both call it
PL> "Skidoo" (but they will have different URLs for the extension, of course),
PL> and still allow both to be used in one request.
I think that having different URLs to identify the extentions is
sufficient; if the extentions are so incompatible that they cannot
be used in the same header syntax unambiguously, then they shouldn't
be implemented in the same place anyway.
I don't want to have to (won't) implement a parser that can deal
with:
GET /xyz HTTP/1.1
Host: foobar
23-Skidoo: abc
65-Skidoo: def
Man: "http://screwball.org/skidoo.html"; ns=23-,
"http://nutcase.org/skidoo.html"; ns=65-
by having to backtrack my parser to remove the 23- and recognize the
'Skidoo'; by the time I get to the Man header, I've seen the
two numeric prefix headers and discarded them as unrecognized (and
therefor automatically optional) headers.
Even supposing hypothetically that we did do this, what happens to
the headers now - granted we separated them for transmission, but
internally the values will be combined anyway as though they were
sent as
Skidoo: abc, def
because that is what header folding rules say we should be able to
do.
We're close to having a registry for header field names anyway; I
just don't think that this extra complexity is warranted.
--
Scott Lawrence EmWeb Embedded Server <lawrence@agranat.com>
Agranat Systems, Inc. Engineering http://www.agranat.com/
Received on Tuesday, 20 January 1998 14:43:11 UTC