Interpreting "+" in query component of https:// scheme URIs.

Matt Randall <matthew.a.randall@gmail.com> Wed, 14 September 2016 08:12 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 97E2D12B5D0 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 14 Sep 2016 01:12:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.427
X-Spam-Level:
X-Spam-Status: No, score=-8.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, 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.508, 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 i6RRlPKXF6Ra for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 14 Sep 2016 01:12:20 -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 CA8E812B5CF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 14 Sep 2016 01:12:20 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bk5D6-0008Lq-Rn for ietf-http-wg-dist@listhub.w3.org; Wed, 14 Sep 2016 08:06:24 +0000
Resent-Message-Id: <E1bk5D6-0008Lq-Rn@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 <ylafon@w3.org>) id 1bk5Cv-0008KZ-2f for ietf-http-wg@listhub.w3.org; Wed, 14 Sep 2016 08:06:13 +0000
Received: from raoul.w3.org ([128.30.52.128]) by lisa.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1bk5Ct-0002vo-6H for ietf-http-wg@w3.org; Wed, 14 Sep 2016 08:06:12 +0000
Received: from homard.platy.net ([80.67.176.7] helo=[192.168.1.41]) by raoul.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1bk5Cs-000GTc-NW for ietf-http-wg@w3.org; Wed, 14 Sep 2016 08:06:10 +0000
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_846D034E-2DC2-4A76-8B77-1875107ABADA"
From: Matt Randall <matthew.a.randall@gmail.com>
Resent-From: Yves Lafon <ylafon@w3.org>
Date: Fri, 09 Sep 2016 22:35:29 +0000
Resent-Date: Wed, 14 Sep 2016 10:06:08 +0200
Resent-To: ietf-http-wg@w3.org
X-Name-Md5: efe3dad792d606410c9cc49cedaffc94
Message-Id: <CANDH0ys6cLwGhRF+9DOTohczajCCR6LWppFpU6Ctr0DBJvZPhA@mail.gmail.com>
To: ietf-http-wg@w3.org
X-Mailer: Apple Mail (2.3124)
X-W3C-Hub-Spam-Status: No, score=-3.7
X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1, BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RP_MATCHES_RCVD=-2.216, W3C_NW=0.5
X-W3C-Scan-Sig: lisa.w3.org 1bk5Ct-0002vo-6H 0dbc3b3d7757782cd92de3f4b12b12e6
X-Original-To: ietf-http-wg@w3.org
Subject: Interpreting "+" in query component of https:// scheme URIs.
Archived-At: <http://www.w3.org/mid/CANDH0ys6cLwGhRF+9DOTohczajCCR6LWppFpU6Ctr0DBJvZPhA@mail.gmail.com>
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32392
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>

Hopefully this is a quick question with a straightforward answer.  The https URI scheme (RFC7230) denotes that it simply follows the definition of the query component from the base URI RFC (RFC3986).  Query seems to allow for all reserved and unreserved characters (with some caveats around "?" and "/") in the value, and reserves none of the reserved characters as delimiters.

From purely a specifications perspective, my assumption (absent de-facto legacy behaviors of certain clients and www-form-urlencoded query string behaviors) would be to treat the plus sign literally, just as if I would in the path component.  Would this be a correct interpretation given the following statement in section 2.2?:
If a reserved character is found in a URI component and
no delimiting role is known for that character, then it must be
interpreted as representing the data octet corresponding to that
character's encoding in US-ASCII.

I couldn't find anything in the current specifications that would indicate that "+" has a 
defined delimiting role for the https:// URI scheme.

Thank you in advance,

Matt Randall