W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: p1: HTTP(S) URIs and fragment identifiers

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 20 Apr 2013 18:16:28 +1000
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-Id: <D323C524-1176-46FB-ABC7-727ECA6B2FB9@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>

On 20/04/2013, at 6:07 PM, Julian Reschke <julian.reschke@gmx.de> wrote:

> On 2013-04-20 09:30, Mark Nottingham wrote:
>> 
>> On 20/04/2013, at 5:28 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
>> 
>>> On 2013-04-20 06:07, Mark Nottingham wrote:
>>>> P1 sections 2.7.1 and 2.7.2 define the HTTP and HTTPS URI schemes without fragment identifiers.
>>>> 
>>>> While it's true that HTTP sends these URIs without fragids "on the wire" in the request-target, the schemes *do* allow fragids pretty much everywhere else they're used (including some places in HTTP, e.g., the Location header).
>>>> 
>>>> Given that this is going to be the definition for these URI schemes, and we already require that the fragid be omitted in the request-target, shouldn't the syntax allow a fragment identifier?
>>> 
>>> No.
>>> 
>>> Fragment identifiers are allowed for *any* URI scheme; the scheme definition doesn't need to include it.
>> 
>> 
>> Then why do we include query?
> 
> Because we are defining a <http://greenbytes.de/tech/webdav/rfc3986.html#absolute-uri>.


But this section *isn't* defining just a single protocol element; it's defining the form of HTTP URIs. 

I suspect the right thing to do here is to specify that HTTP(s) URIs use the path-abempty form of the hier-part, give some examples, and leave the rest of the ABNF to RFC3986 (or its successors).

At any rate, I don't see the http-uri or https-uri rules actually used anywhere normatively, so I *think* this is editorial. I.e., it's on your conscience :)

Cheers,


--
Mark Nottingham   http://www.mnot.net/
Received on Saturday, 20 April 2013 08:16:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:12 UTC