Failing Parameter in Key Header

Paul Mansour <paul@carlislegroup.com> Fri, 03 June 2016 09:52 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 E345C12D644 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 3 Jun 2016 02:52:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.346
X-Spam-Level:
X-Spam-Status: No, score=-8.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 rifckWbZp15a for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 3 Jun 2016 02:52:14 -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 6873C12D64B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 3 Jun 2016 02:52:08 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1b8lil-00075Y-A2 for ietf-http-wg-dist@listhub.w3.org; Fri, 03 Jun 2016 09:48:51 +0000
Resent-Message-Id: <E1b8lil-00075Y-A2@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1b8lic-000744-T7 for ietf-http-wg@listhub.w3.org; Fri, 03 Jun 2016 09:48:42 +0000
Received: from raoul.w3.org ([128.30.52.128]) by maggie.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1b8lib-0006vq-Jp for ietf-http-wg@w3.org; Fri, 03 Jun 2016 09:48:42 +0000
Received: from platy.fdn.fr ([80.67.176.7] helo=[192.168.1.40]) by raoul.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1b8lia-0000HY-OX for ietf-http-wg@w3.org; Fri, 03 Jun 2016 09:48:41 +0000
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_B771E9DE-C9ED-4D10-8B86-3534D6596423"
From: Paul Mansour <paul@carlislegroup.com>
Resent-From: Yves Lafon <ylafon@w3.org>
Date: Mon, 30 May 2016 01:07:51 +0000
Resent-Date: Fri, 03 Jun 2016 11:48:38 +0200
Resent-To: ietf-http-wg@w3.org
X-Name-Md5: efe3dad792d606410c9cc49cedaffc94
Message-Id: <46EE7A37651F404F8B5F497D3BA1481499BD0A23@AUSP01DAG0109.collaborationhost.net>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
X-Mailer: Apple Mail (2.3124)
X-W3C-Hub-Spam-Status: No, score=-6.3
X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1b8lib-0006vq-Jp b88b96ee7f67409150a18c3682e6c6e4
X-Original-To: ietf-http-wg@w3.org
Subject: Failing Parameter in Key Header
Archived-At: <http://www.w3.org/mid/46EE7A37651F404F8B5F497D3BA1481499BD0A23@AUSP01DAG0109.collaborationhost.net>
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31695
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>

I am trying to implement the Key header (from https://tools.ietf.org/html/draft-ietf-httpbis-key-01 <https://tools.ietf.org/html/draft-ietf-httpbis-key-01>) and have a question regarding “fail parameter processing”.   I apologize in advance if this question is best for another forum. The Key header does not appear to be widely discussed yet, so I thought this might be the right place.
 
Why is a key-item with zero parameters treated as a “failing parameter” (going to section 2.2.2) when calculating a secondary cache key?  I would have thought that at step 5, sub-step 2, it would read something like:
  
…append “field-value” (or a normalized version of it) to “secondary-key” (and go to next key item)
 
In other words, if there are zero parameters for a key-item, simply append the value of the header field to the secondary-key and then move on to the next key-item. In all other cases when building the cache key, there is an actual error in the parameter (no = sign, bad parameter name, etc.). In the case of zero parameters, it is not really an error, as the spec explicitly allows for zero or more parameters.
 
In addition, and related, and I think more important, it is unclear to me whether or not each key item stands on its own if there is a failing parameter (or as it stands, no parameters) in one of them. In the step-by-step algorithm it seems to indicate that they are independent, as in case of error the instruction is to move on to the next key-item (after handling the error). But in the failing parameter processing section 2.2.2 it seems to indicate that if there is a single failing parameter, the entire Key header should be ignored (falling back to Vary I assume) or that all of the “nominated header fields being compared match” which is the same as treating the Key header as a Vary header with no parameters for any nominated header field. In either case, one failing parameter in one key-item appear to void all parameters in all key-items.
 
Is the spec unclear here, or am I just not getting it?
 
Thanks,
 
Paul Mansour