IETF Logo Mail Archive

Re: JSON headers

Julian Reschke <julian.reschke@gmx.de> Sun, 10 July 2016 12:35 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F89A12D143 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 10 Jul 2016 05:35:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.208
X-Spam-Level:
X-Spam-Status: No, score=-8.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esXcmrqGcEM7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 10 Jul 2016 05:35:57 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D59512D0C0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 10 Jul 2016 05:35:57 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bMDto-0007X2-Vo for ietf-http-wg-dist@listhub.w3.org; Sun, 10 Jul 2016 12:31:53 +0000
Resent-Date: Sun, 10 Jul 2016 12:31:52 +0000
Resent-Message-Id: <E1bMDto-0007X2-Vo@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <julian.reschke@gmx.de>) id 1bMDtl-0007WH-L5 for ietf-http-wg@listhub.w3.org; Sun, 10 Jul 2016 12:31:49 +0000
Received: from mout.gmx.net ([212.227.15.15]) by lisa.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <julian.reschke@gmx.de>) id 1bMDtf-0005So-MA for ietf-http-wg@w3.org; Sun, 10 Jul 2016 12:31:49 +0000
Received: from [192.168.178.20] ([93.217.120.27]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LaFmY-1aylJA1JtO-00m2eE; Sun, 10 Jul 2016 14:31:10 +0200
To: Yanick Rochon <yanick.rochon@gmail.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>
References: <74180.1468000149@critter.freebsd.dk> <A17D3EFD-A935-4971-BCF6-DC9D38302CAD@oracle.com> <564a72e8-b9d3-1f9c-5982-48f2b07272e5@greenbytes.de> <3924.1468137899@critter.freebsd.dk> <683f5f58-6046-d9fb-cc75-d0ab3890ce23@greenbytes.de> <4105.1468141779@critter.freebsd.dk> <5cdf0fa8-063c-7eaa-a9e3-fb6db7417254@gmx.de> <4213.1468143913@critter.freebsd.dk> <94e4a5c2-3465-fef3-6221-d9f4fcccb5fa@gmx.de> <4324.1468145426@critter.freebsd.dk> <CAB0No9kf6gje3Tc+impphV5tUHjksCkL1PJ1YAgNjXO+tLq=XA@mail.gmail.com>
Cc: Phil Hunt <phil.hunt@oracle.com>, HTTP Working Group <ietf-http-wg@w3.org>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <176d58df-debf-e660-edf7-7d686c926ef6@gmx.de>
Date: Sun, 10 Jul 2016 14:31:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAB0No9kf6gje3Tc+impphV5tUHjksCkL1PJ1YAgNjXO+tLq=XA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:ogqQvZiak9f0NjvYV1aLkmGt+n8Swo4vxoPMImgYB9SmTXeqj+4 +Imxo8QEyEkUwHDlWjOQuJsMhwHl/d4U35clIARSNlsR1E91aS1ILwSRszG/7ztcQDvEA// y77FmXq9z0fwXDHZWSUTeeq38eifOILUZt8usnhnPkqLdvnyGcrFSc7iGnExvBmwZJDL5Kx 4Pu/hq8OJJEyE6eUFAmOw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:Oxkp6UrJT6o=:vKaZwfcjhBVE8SJ6bGbYYX otXuau1fXpwY+tElFi0/1xipyB/Vb/TRsVFSCEzct5ItDaiil3aDh/kTBEGzeVZHfKrB1bbJK TBqkqbOgoTwbPstdIhxzkSDpxLI0B0cO4oPrnL3PRmOFWrDZgPhf8y4xlOTt0QgMtGn5GhnSH NPqPQ12FT0fAAUeU5Q99R5CW9f5SuwQ/9QtxAfaLG4Qu/uIlpGIKnsJd2rkJ0m4XwchR2fTEg m5mFLT3h4uOnQ0BPVpKMhMpmksg9P8oByIZZYQJ3u/gxcBevDe/NYoiXBVzqUckO5eUmLcK3/ E+YW6M00S8vyCwGr/o9zB4WeZyEH4q22sLRiEz+vBB5bPY7MZIVYZiO+sHKC68cRw4wMJyPID 1d0a9dX1SUg6u28sQX5Qfh+ZyXeFnOp24T56C5UI7D65wyJfYjUpVmq8+8Tqgnnp5wQ24Kx7h O+gV4ej+f+TDcZ4Ja62+wVD7ArUaxTMiibxbFCuPLqPnRKi/BjvXOBV5zYgKN82OMU5q6yv6K V++llNcT7Amm8/LO3ZrDKYH0lsmirorJbQMQOerg8BacZK8hIw9gH+4DVUgbMEHJGRMuBwioj akrOgShgrARxAtlg7zjyIQNTKQNAtZaiGusaKHMv0FRu5T2NzBOHUMv7M1GnhoobpOjBZZCve OCSeWNeYCordXDFwC6e/LNh0Xa0e5sntLyt40jP02StPyqeFPO9P5T5HIVOjwtOEi0zQxiLgJ AAxE8hprSjdZoASerDIo20MST+6hyxNPVMh6Nlmau8mxPPI1R+izSwmeObAnCUsrXUYAdnzF6 rydYVr0
Received-SPF: pass client-ip=212.227.15.15; envelope-from=julian.reschke@gmx.de; helo=mout.gmx.net
X-W3C-Hub-Spam-Status: No, score=-6.7
X-W3C-Hub-Spam-Report: AWL=-0.075, BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1bMDtf-0005So-MA f2abf8751505d575f4e90a104acef8db
X-Original-To: ietf-http-wg@w3.org
Subject: Re: JSON headers
Archived-At: <http://www.w3.org/mid/176d58df-debf-e660-edf7-7d686c926ef6@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31863
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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

v2.23.0 | Report a Bug | By Email