- 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