Subject: [hybi] Editorial issue: Ignoring rather than failing on URI fragments

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Mon, 9 May 2011 17:04:49 +0000

Regarding handling URI fragments, section 3.1 [0] of the 07 draft states in point 4 that 

    4.   If /uri/ has a <fragment> component, then fail this algorithm.

However, the "XMLHttpRequest, W3C Candidate Recommendation 3 August 2010" specification states that the caller is supposed to DROP the fragment (i.e. to ignore, not to fail): 

    1. Let url be a URL. 
    2. Let URL character encoding of url be UTF-8. 
    3. Resolve url relative to the XMLHttpRequest base URL. If the algorithm returns an error raise a SYNTAX_ERR exception and terminate these steps. 
    4. Drop <fragment> from url. 

This is also the correct behavior for HTTP clients and consistent with URI semantics. 

I propose that the text be changed to the following:

    4.   If /uri/ has a <fragment> component, then drop it.

Thanks,

Henrik

[0] http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07#section-3.1
[1] http://www.w3.org/TR/XMLHttpRequest/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 May 2011 19:31:50 +0200

Again,

the whole section should go. URIs are URIs and should be handled like 
URIs :-).

On 09.05.2011 19:04, Henrik Frystyk Nielsen wrote:
>      4.   If /uri/ has a<fragment>  component, then fail this algorithm.
>
>      4. Drop<fragment>  from url.
>
>      4.   If /uri/ has a<fragment>  component, then drop it.
>
> Thanks,
>
> Henrik
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Mon, 9 May 2011 21:56:15 +0000

I love it! I was trying to keep the suggestion small but I like this much better.

Henrik

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Monday, May 09, 2011 10:32 AM
To: Henrik Frystyk Nielsen
Cc: Hybi ([email-masked])
Subject: Re: [hybi] Editorial issue: Ignoring rather than failing on URI fragments

Again,

the whole section should go. URIs are URIs and should be handled like URIs :-).

On 09.05.2011 19:04, Henrik Frystyk Nielsen wrote:
> [0] 
> http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07#sec
> tion-3.1 [1] http://www.w3.org/TR/XMLHttpRequest/
>

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 10 May 2011 10:45:36 +1000

> the whole section should go. URIs are URIs and should be handled like URIs

Ian,

This suggestion has been made many times now and widely supported each time.
Has anybody made a good argument to keep URI parsing algorithms in the
document?   If not can we please just drop this section and get off
this particular hamster wheel.

cheers

---

From: "Simon Pieters" <[email-masked]>
Date: Tue, 10 May 2011 10:26:08 +0200

On Tue, 10 May 2011 02:45:36 +0200, Greg Wilkins <[email-masked]> wrote:

>> URIs
>> :-).

If the section is dropped, it would just move the steps into the other  
sections that use the output of the algorithm. AFAICT it doesn't redefine  
how to parse URIs. Without this section the "establish a websocket  
connection" would need to contain the same logic to figure out which host  
and port to open a connection to, whether to use TLS or not, and so forth.  
That seems like an editorial matter that I would leave to the editor to  
decide which is easier to spec.

Whether to fail to open a connection or not when the <fragment> is present  
is not editorial, however. (Either way is fine for me.)

-- 
Simon Pieters
Opera Software

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 May 2011 10:37:54 +0200

On 10.05.2011 10:26, Simon Pieters wrote:
> sections that use the output of the algorithm. AFAICT it doesn't
> redefine how to parse URIs. Without this section the "establish a
> websocket connection" would need to contain the same logic to figure out
> which host and port to open a connection to, whether to use TLS or not,
> and so forth. That seems like an editorial matter that I would leave to
> the editor to decide which is easier to spec.

The algorithm can be replaced by a short paragraph that defines the ABNF 
for "ws" and "wss" (optimally in terms of RFC 3986) and defines the 
default port numbers.

> Whether to fail to open a connection or not when the <fragment> is
> present is not editorial, however. (Either way is fine for me.)

Best regards, Julian

---

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Tue, 10 May 2011 17:46:23 +0000

Julian,

Would you be willing to provide a proposal for such a paragraph? It may make it easier to discuss.

> The algorithm can be replaced by a short paragraph that defines the ABNF for
> "ws" and "wss" (optimally in terms of RFC 3986) and defines the default port
> numbers.

Thanks,

Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 May 2011 20:17:32 +0200

On 10.05.2011 19:46, Henrik Frystyk Nielsen wrote:
> ...

Yes. I'll try to get this done tomorrow.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 May 2011 15:09:06 +0200

>> "ws" and "wss" (optimally in terms of RFC 3986) and defines the default port

I was thinking about something like:

3. WebSocket URIs

This specification defines two URI schemes, using the ABNF syntax 
defined in [RFC5234], and terminology and ABNF productions defined by 
the URI specification ([RFC3986]).

   ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
   wss-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]

   host = <host, defined in [RFC3986], Section 3.2.2>
   port = <host, defined in [RFC3986], Section 3.2.3>
   path = <path-abempty, defined in [RFC3986], Section 3.3>
   query = <query, defined in [RFC3986], Section 3.4>

The port component is OPTIONAL; the default for "ws" is port 80, and the 
default for "wss" is port 443.

The URI is called "secure" if the scheme component matches "wss" 
case-insensitively.

The "resource-name" can be constructed by concatenating:

- "/" if the path component is empty,
- the path component
- "?" if the query component is non-empty, and
- the query component

OPEN: unsure about the case-normalization for "host", what is it fore
OPEN: unsure about the IDNA requirements
OPEN: 3.2 and 3.3 seem to just state the obvious

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 12 May 2011 03:07:23 +0200

* Henrik Frystyk Nielsen wrote:
>However, the "XMLHttpRequest, W3C Candidate Recommendation 3 August
>2010" specification states that the caller is supposed to DROP the
>fragment (i.e. to ignore, not to fail):

That is essentially an error in the XMLHttpRequest specification. I do
not recall whether we discussed this in detail back in the day, but it
is in any case likely though that different behavior would trigger
compatibility problems, so that behavior got specified.

It is a design error because there is no reason to specify a fragment
identifier and then have it ignored, beyond perhaps convenience in that
users of the interface do not need to pay attention to stripping frag-
ments from the resource identifier.

Unlike the HTTP scheme the Websocket scheme does not map to something
that has media type information; since the interpretation of fragment
identifiers depends on the underlying media type, it is essentially an
error to ever create "ws" identifiers with fragment identifiers.

More importantly, if fragment identifiers that would otherwise be ig-
nored trigger errors, then it is possible to associate meaning to the
fragment identifiers later. There are efforts to do just that, e.g.,
http://www.w3.org/TR/2011/WD-media-frags-20110317/ does it, but making
that work with XMLHttpRequest in some natural manner is complicated as
XMLHttpRequest ignores the fragment.

So, I would be rather sceptical that ignoring the fragment identifier
is the best approach for Websocket. That however is a concern for any
Websocket API, not so much a concern for the on-the-wire protocol, so
this working group's specification should say that handling of fragment
identifiers is out of scope and needs to be addressed by higher level
specifications.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 May 2011 09:34:08 +0200

> identifiers is out of scope and needs to be addressed by higher level

What we should make clear is that although fragment identifiers 
currently do not make sense with websockets URIs, this does *not* affect 
the syntax. So if you need a literal "#" in a WS URI, you will have to 
percent-escape it.

Best regards, Julian

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 12 May 2011 19:05:36 +0900

> the syntax. So if you need a literal "#" in a WS URI, you will have to

Yes for escaping. Also yes for 'currently'. It may well be that some 
subprotocol or extension will create some rather interesting and valid 
ways of using fragment identifiers, and we should keep that door open.

BTW, mailto: is in a very similar situation. Fragment identifiers 
currently don't make sense in mailto: URIs, and there is explicit test 
to this effect in http://tools.ietf.org/html/rfc6068 (just search for 
fragment).

Regards,    Martin.