Re: draft-fielding-http-key-02 obvious shortcoming & failure

Mark Nottingham <mnot@mnot.net> Sun, 28 July 2013 06:52 UTC

Return-Path: <ietf-http-wg-request@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 2312A21F9D53 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 27 Jul 2013 23:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level:
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzV-CfNiwrag for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 27 Jul 2013 23:52:19 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 42D9621F95DC for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 27 Jul 2013 23:52:19 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1V3Kod-00088z-U3 for ietf-http-wg-dist@listhub.w3.org; Sun, 28 Jul 2013 06:50:51 +0000
Resent-Date: Sun, 28 Jul 2013 06:50:51 +0000
Resent-Message-Id: <E1V3Kod-00088z-U3@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1V3KoR-000887-Gb for ietf-http-wg@listhub.w3.org; Sun, 28 Jul 2013 06:50:39 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1V3KoQ-0000rW-PQ for ietf-http-wg@w3.org; Sun, 28 Jul 2013 06:50:39 +0000
Received: from [10.20.21.187] (unknown [195.202.153.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9885422E1FA; Sun, 28 Jul 2013 02:50:16 -0400 (EDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <1374777546.18069.30.camel@localhost>
Date: Sun, 28 Jul 2013 08:50:15 +0200
Cc: "Roy T. Fielding" <fielding@gbiv.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A3A11B69-FF41-4616-A670-9448CDB006EF@mnot.net>
References: <1374777546.18069.30.camel@localhost>
To: =?iso-8859-1?Q?Henrik_Nordstr=F6m?= <henrik@henriknordstrom.net>
X-Mailer: Apple Mail (2.1508)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-0.0
X-W3C-Hub-Spam-Report: SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1V3KoQ-0000rW-PQ 451eef04d188e4811a7a960f5e6e2cc0
X-Original-To: ietf-http-wg@w3.org
Subject: Re: draft-fielding-http-key-02 obvious shortcoming & failure
Archived-At: <http://www.w3.org/mid/A3A11B69-FF41-4616-A670-9448CDB006EF@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18936
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>

Hi Henrik,

Yes, we're aware of that. 

We're trying to find the right level of complexity and capability for the draft, and biased towards "simple" very early. As we get some implementation experience and evolve the draft, we'll address this.

Cheers,


On Jul 25, 2013, at 8:39 PM, Henrik Nordström <henrik@henriknordstrom.net> wrote:

> Learnt about the Key draft today in another discussion about how to
> cache Vary responses, and reading the document I see a noticeble
> shortcoming and failure of the proposed algorithm.
> 
> In "2.2.4. "p": Parameter Prefix Match Modifier" you have
> 
> Key: Accept;p="text/html"
> 
> And a seemingly nice looking list of things it matches and do not match.
> So far so good. But it will also match
> 
> Accept: text/plain;q=0
> 
> which is the opposite. Here the client says it do not accept text/plain.
> 
> same issue applies to any other header using quality attribute.
> 
> It also fails to represent quality selection among different variants in
> general. I.e. when there is both text/html and text/plain versions and
> one client prefers plain, the other html but both can process both.
> 
> Regards
> Henrik
> 

--
Mark Nottingham   http://www.mnot.net/