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

I like Mark's idea better. In many contexts when people use the term
HTTP URI they would consider fragment a legit optional part, so the
spec should not appear to exclude it in general.

Zhong Yu

On Sat, Apr 20, 2013 at 3:16 AM, Mark Nottingham <mnot@mnot.net> wrote:
>
> 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 16:40:21 UTC