#474, was: WGLC p7: Parsing auth challenges

Julian Reschke <julian.reschke@gmx.de> Sun, 09 June 2013 16:45 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 97F4221F9273 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 9 Jun 2013 09:45:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 C4l0Rzy53dXe for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 9 Jun 2013 09:45:46 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC0F21F8EAE for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 9 Jun 2013 09:45:45 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UlikH-00042i-I3 for ietf-http-wg-dist@listhub.w3.org; Sun, 09 Jun 2013 16:45:33 +0000
Resent-Date: Sun, 09 Jun 2013 16:45:33 +0000
Resent-Message-Id: <E1UlikH-00042i-I3@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <julian.reschke@gmx.de>) id 1Ulik3-00041z-Fz for ietf-http-wg@listhub.w3.org; Sun, 09 Jun 2013 16:45:19 +0000
Received: from mout.gmx.net ([212.227.15.19]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <julian.reschke@gmx.de>) id 1Ulik2-0005W8-QW for ietf-http-wg@w3.org; Sun, 09 Jun 2013 16:45:19 +0000
Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MckDn-1V3f7s0Sqv-00HxYI for <ietf-http-wg@w3.org>; Sun, 09 Jun 2013 18:44:53 +0200
Received: (qmail invoked by alias); 09 Jun 2013 16:44:52 -0000
Received: from p5DD94783.dip0.t-ipconnect.de (EHLO [192.168.2.117]) [93.217.71.131] by mail.gmx.net (mp019) with SMTP; 09 Jun 2013 18:44:52 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+49GdPsz+4jOVHroRxrAbeUDtp3XQawUzerNuygC C93bNtrBnw4/C/
Message-ID: <51B4B102.1000508@gmx.de>
Date: Sun, 09 Jun 2013 18:44:50 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: John Sullivan <jsullivan@velocix.com>
CC: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>, HTTP Working Group <ietf-http-wg@w3.org>
References: <8F6FB0A1-4D7E-4847-92A7-14B240FAC23A@niven-jenkins.co.uk> <517FAE54.5070801@gmx.de> <517FCAE5.7050507@velocix.com> <517FCFD2.10609@gmx.de>
In-Reply-To: <517FCFD2.10609@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass client-ip=212.227.15.19; envelope-from=julian.reschke@gmx.de; helo=mout.gmx.net
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-2.456, BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1Ulik2-0005W8-QW 221790f0e7ed0650d9099f39f9c5cd3b
X-Original-To: ietf-http-wg@w3.org
Subject: #474, was: WGLC p7: Parsing auth challenges
Archived-At: <http://www.w3.org/mid/51B4B102.1000508@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18203
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 2013-04-30 16:06, Julian Reschke wrote:
> On 2013-04-30 15:45, John Sullivan wrote:
>> Julian Reschke wrote:
>>> On 2013-04-29 20:55, Ben Niven-Jenkins wrote:
>>>> (And if we don't get something, after whitespace elimination, which
>>>> is either the end of the header field value or a token after the
>>>> ",", then the value is invalid and should be rejected.)
>>>
>>> You could have an empty list entry, such as in
>>>
>>>    WWW-Authenticate: Basic realm="foo", , Basic realm="bar"
>>
>> Ah yes, of course. I always assume that basic #rule processing,
>> including eliminating empty entries, has been done at a lower
>> layer so at this level the comma "doesn't exist" - but if we're
>> talking about sequences including the "," here, that is an
>> inconsistent way of describing it.
>
> #rule processing can not happen at a lower layer because if requires
> knowledge of the ABNF for "rule".
>
>> (And if we get a non-empty string, after whitespace elimination,
>> between the "," but before the earlier of either the end of the
>> header field value or the next ",", which is not a token then the
>> value is invalid and should be rejected.)
>>
>>>> If that interpretation is correct, it would be helpful to state this
>>>> clearly, rather than merely infer it. (And if that interpretation is
>>>> not correct, clearly relying on inference alone is unreliable!)
>>>
>>> The interpretation is correct. Can you make a more concrete proposal?
>>>
>>>> There is perhaps still the question of whether in the face of
>>>> multiple WWW/Proxy-Authenticate headers, the implied "," separating
>>>> their values according to #rule is still allowed to operate at both
>>>> levels of the grammar, or only at the outermost (#challenge) level.
>>>
>>> Not sure about what you're asking. Can you provide an example?
>>
>> WWW-Authenticate: chal1 param1p1=val , param1p2=val, chal2 param2p1=val
>>
>> Should clearly be equivalent to:
>>
>> WWW-Authenticate: chal1 param1p1=val , param1p2=val
>> WWW-Authenticate: chal2 param2p1=val
>
> Yes.
>
>> It also should (according to the above rules) be equivalent to:
>>
>> WWW-Authenticate: chal1 , param1p1=val , param1p2=val, chal2 param2p1=val
>>
>> And of course:
>>
>> WWW-Authenticate: , chal1 , param1p1=val , param1p2=val, chal2
>> param2p1=val
>>
>> WWW-Authenticate: chal1 , param1p1=val , , param1p2=val, chal2
>> param2p1=val
>>
>> WWW-Authenticate: chal1 , param1p1=val , param1p2=val, chal2
>> param2p1=val,
>
> Yes.
>
>> But what about:
>>
>> WWW-Authenticate: chal1 param1p1=val
>> WWW-Authenticate: param1p2=val, chal2 param2p1=val
>>
>> This *could* be unambiguously parsed as equivalent to the above,
>> but feels a bit shakier to allow. OTOH dumb processors assuming
>> #rule might transform in or out of that form (by breaking on an
>> arbitrary unencoded comma or squashing any #rule headers into a
>> single instance).
>
> Yes. It's invalid (each header field instance needs to conform to
> #challenge), but folding it into a single string may make it valid-
>
>> On that matter I just also noticed:
>>
>> WWW-Authenticate: chal2
>> WWW-Authenticate: param2p1=val
>>
>> Which looks similar but is probably disallowed by the grammar as
>> it stands: the param list is optional, but if present must be
>> separated by 1*SP (and any such you attempted to put in wouldn't
>> form part of field-value.)
>
> It's as invalid as the previous example.
>
>> Going back up a bit, compare:
>>
>> Apparently allowed:
>> WWW-Authenticate: chal1 , param1p1=val , param1p2=val, chal2 param2p1=val
>>
>> Apparently invalid:
>> WWW-Authenticate: chal1, param1p1=val , param1p2=val, chal2 param2p1=val
>> ...
>
> Yes.
>
> The syntax for WWW-A is a big mess. Not sure what we can do here in the
> spec though.
>
> Best regards, Julian
> ...

I'd like to close this issue unless somebody can come up with a concrete 
change proposal.

Best regards, Julian