- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 10 Jul 2016 14:31:09 +0200
- To: Yanick Rochon <yanick.rochon@gmail.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Phil Hunt <phil.hunt@oracle.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 2016-07-10 14:03, Yanick Rochon wrote: > On 10 July 2016 at 06:10, Poul-Henning Kamp <phk@phk.freebsd.dk > <mailto:phk@phk.freebsd.dk>> wrote: > > -------- > In message <94e4a5c2-3465-fef3-6221-d9f4fcccb5fa@gmx.de > <mailto:94e4a5c2-3465-fef3-6221-d9f4fcccb5fa@gmx.de>>, Julian > Reschke writes > : > > >But right now the spec *is* written to use the list construct, and I > >believe that's a good thing, as it's IMHO better to consider multiple > >instances as legal, and require the definition of the header field to > >deal with it. > > I think it is a bad thing. > > It prevents streaming processing of headers, since you never know > when you have the full picture for a particular header, until you've > received them all and seen that there are no more instances. > > It means also means that either you have to rewrite the headers, or > all your code needs to do the brute-force collection scan and handle > an array of headers for further processing. Both of which is wasteful > in terms of CPU and memory. > > I see no advantages that come even close to compensating for those > disadvantages, but if I have overlooked something, please enlighten > me... > > > I agree. Normally, multiple instances are legal in JSON and the latest > will simply override the previous one, but in the case of headers, it is > not good indeed and may produce problem when a repeating header comes > after a few preliminary configurations have been set and will force > retrieving the entire header object instead of the actual implementation > (i.e. it would be a regression, not an improvement). Since streaming > headers (feasable in JSON) is preferrable, duplicated keys in the JSON > header should either be ignored or rejected with an error. It is the > responsibility of the sender to properly format it's header before > sending, not the server to untangle a messy one. In my opinion, > repeating headers should be put in an array, period. It seems you are confusing several issues here: multiple header field instances in the HTTP message, and duplicate member names in a JSON object. These are completely orthogonal issues. Best regards, Julian
Received on Sunday, 10 July 2016 12:31:49 UTC