Re: [apps-discuss] Fun with URLs and regex

Mark Nottingham <> Wed, 28 January 2015 01:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D2E021A1ABE for <>; Tue, 27 Jan 2015 17:54:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Yoj6yMU3DGrw for <>; Tue, 27 Jan 2015 17:53:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C4691A1AB1 for <>; Tue, 27 Jan 2015 17:53:59 -0800 (PST)
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id A5E0722E261; Tue, 27 Jan 2015 20:53:52 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Wed, 28 Jan 2015 12:53:48 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Sam Ruby <>
X-Mailer: Apple Mail (2.1993)
Archived-At: <>
Cc: Alex Russell <>, Domenic Denicola <>, IETF Apps Discuss <>
Subject: Re: [apps-discuss] Fun with URLs and regex
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Jan 2015 01:54:02 -0000

Hi Sam,

> On 9 Jan 2015, at 3:54 am, Sam Ruby <> wrote:
> Mark cares about valid URIs.  He's certainly not alone in that.  What he has done is express his interests not merely in high level prose, but in concrete, executable form.  Given that he has done that, I can pose some interesting questions.  For example, if you consider the process of canonicalizing a href value on an <a> element and stringifying the result, an implementation like Chrome will produce something that will be sent across the wire.  I've captured the results here:
> Given that data and Mark's script, I can produce a list of outputs that Mark doesn't consider valid:


> With this data, we can have a discussion as to whether Mark's script should be updated, or Chrome should change, or some spec should change.

What I was hoping for was an update of the "valid URI" filter to take this into account at <>.

E.g., that list currently includes test case 63, "https:/", which is valid according to the generic syntax in RFC3986, but not when you consider the scheme-specific constraints for HTTPS in RFC7230.

By filtering out these cases, we can see the places we potentially need to pay attention to in the RFCs.

Is that possible?


Mark Nottingham