Re: p1: whitespace in request-target

"Roy T. Fielding" <fielding@gbiv.com> Sun, 19 May 2013 20:00 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 5F74021F8D71 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 19 May 2013 13:00:05 -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 IC-Ao4pCS64e for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 19 May 2013 12:59:59 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 825E821F84AF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 19 May 2013 12:59:59 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Ue9l9-000641-Ol for ietf-http-wg-dist@listhub.w3.org; Sun, 19 May 2013 19:59:11 +0000
Resent-Date: Sun, 19 May 2013 19:59:11 +0000
Resent-Message-Id: <E1Ue9l9-000641-Ol@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <fielding@gbiv.com>) id 1Ue9ky-00062s-3A for ietf-http-wg@listhub.w3.org; Sun, 19 May 2013 19:59:00 +0000
Received: from caiajhbdccac.dreamhost.com ([208.97.132.202] helo=homiemail-a28.g.dreamhost.com) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <fielding@gbiv.com>) id 1Ue9kx-0004oe-9S for ietf-http-wg@w3.org; Sun, 19 May 2013 19:59:00 +0000
Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 707471B4059; Sun, 19 May 2013 12:58:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=+IKerHPYPINF0P020lTma6BEbLM=; b=0IjQmVAfxvLtPuzTjTT+sKO3xbuA 2oa5XGWf/aXrk1OCkClY05XpkawfXMEcd+ebZBmtx8ldrCXKehMNplDK9DEKKmii pqaV3JcS4h6ZkR2jWkbSXlWq5jxZ2HvlvooEcl8XxjOp9VQ8J8TcojPME4RlzILZ NuHalgUFHx9upjY=
Received: from [192.168.1.84] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 471DF1B4058; Sun, 19 May 2013 12:58:38 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <20130430055251.GC21517@1wt.eu>
Date: Sun, 19 May 2013 12:58:47 -0700
Cc: Mark Nottingham <mnot@mnot.net>, Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <04F00D4A-09EE-4729-AB44-EAD26522192E@gbiv.com>
References: <2183465A-F833-4701-A55C-EC105A36329E@mnot.net> <516F6CF9.30709@treenet.co.nz> <84716645-4097-4014-BB4A-3A8C5BF5DD4E@mnot.net> <20130430055251.GC21517@1wt.eu>
To: Willy Tarreau <w@1wt.eu>
X-Mailer: Apple Mail (2.1283)
Received-SPF: none client-ip=208.97.132.202; envelope-from=fielding@gbiv.com; helo=homiemail-a28.g.dreamhost.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-3.436, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001
X-W3C-Scan-Sig: lisa.w3.org 1Ue9kx-0004oe-9S e3103bf05d0b43e00e15f6aa6d8678ac
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p1: whitespace in request-target
Archived-At: <http://www.w3.org/mid/04F00D4A-09EE-4729-AB44-EAD26522192E@gbiv.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18027
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 Apr 29, 2013, at 10:52 PM, Willy Tarreau wrote:

> On Tue, Apr 30, 2013 at 01:18:43PM +1000, Mark Nottingham wrote:
>> So, I'm not hearing you say "don't make this a MUST" -- just noting that some
>> broken software out there; correct?
> 
> Amos' last sentence makes me understand "please don't make this a MUST" :
> 
>> The actual security worst-case risk of this undeterminable, but its
>> not going to be good for the transaction at the best of times
> 
> And I also agree with him that the wording currently is ambiguous because
> it can either be understood as "servers and intermediaries should do this
> since they're accepting user-typed URIs" or as "clients should fix user-
> typed requests before sending".
> 
> Thus in order to avoid any ambiguity, I would propose two sentences instead
> of one :
> 
>>  For robustness, software that accepts user-typed URI should attempt
>>  to recognize and strip both delimiters and embedded whitespace.

Which is in RFC3986, not the HTTP specs, and is clearly referring
to user agent software, not Squid.

> Would become :
> 
>    Clients MUST NOT send user-typed delimiters and embedded whitespaces
>    as-is in URIs, and SHOULD either encode them, strip them. Alternatively
>    they MAY simply refuse to perform the request.
> 
>    Servers and intermediaries MUST NOT try to fix embedded spaces and
>    delimiters in URIs, as doing so could lead to interoperability issues
>    and make several components in the chain understand different things.
>    When a request does not parse exactly as defined in the ABNF, an error
>    400 (Bad Request) MUST be returned to the client.
> 
> Comments ?

The text currently in p1 (latest) is

   The request-target identifies the target resource upon which to apply
   the request, as defined in Section 5.3.

   Recipients typically parse the request-line into its component parts
   by splitting on whitespace (see Section 3.5), since no whitespace is
   allowed in the three components.  Unfortunately, some user agents
   fail to properly encode or exclude whitespace found in hypertext
   references, resulting in those disallowed characters being sent in a
   request-target.

   Recipients of an invalid request-line SHOULD respond with either a
   400 (Bad Request) error or a 301 (Moved Permanently) redirect with
   the request-target properly encoded.  Recipients SHOULD NOT attempt
   to autocorrect and then process the request without a redirect, since
   the invalid request-line might be deliberately crafted to bypass
   security filters along the request chain.

I think the requirement is adequately explained.  It is a SHOULD instead
of a MUST because there was no specific error handling defined for this
case in 2616.

....Roy