Subject: [hybi] WS URLs

From: Tobias Oberstein <[email-masked]>
Date: Sat, 22 Oct 2011 14:40:20 -0700

2 short questions .. first one is part of http://bugs.python.org/issue13244

Which of the following URLs are valid WS URLs?

1. ws://example.com/something#somewhere
2. ws://example.com/something#somewhere/
3. ws://example.com/something#somewhere/foo
4. ws://example.com/something?query=foo#bar
5. ws://example.com/something%23somewhere
6. ws://example.com/something%23somewhere/
7. ws://example.com/something%23somewhere/foo
8. ws://example.com/something?query=foo%23bar

%23 = # "percentage escaped"

Hybi-17 spec:

"Fragment identifiers are meaningless in the context of WebSocket
URIs, and MUST NOT be used on these URIs.  The character "#" in URIs
MUST be escaped as %23 if used as part of the query component."

"path = <path-abempty, defined in [RFC3986], Section 3.3>"

http://tools.ietf.org/html/rfc3986:

"The path is terminated by the first question mark ("?") or number sign ("#") character, or by the end of the URI."

==

When an invalid WS URLs is received in the client request during opening handshake,
how is the server supposed to react?

Fail the handshake (i.e. http 400 Bad request), or "ignore" invalid parts (like fragment component)?

---

From: Tobias Oberstein <[email-masked]>
Date: Sat, 22 Oct 2011 14:57:04 -0700

sorry, I missed the posts by Peter and Julian

http://www.ietf.org/mail-archive/web/hybi/current/msg09243.html

So 1. - 4. are invalid, and 5. - 8. are valid?

What about failing the handshake vs ignoring a fragment component (introduced via non-escaped #)?

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
> Tobias Oberstein
> Gesendet: Samstag, 22. Oktober 2011 23:40
> An: [email-masked]
> Betreff: [hybi] WS URLs
> 
> "Fragment identifiers are meaningless in the context of WebSocket URIs, and
> MUST NOT be used on these URIs.  The character "#" in URIs MUST be
> escaped as %23 if used as part of the query component."
> 
> When an invalid WS URLs is received in the client request during opening
> handshake, how is the server supposed to react?
> 
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 24 Oct 2011 14:02:36 +0100

Hi Tobias,

> 4. ws://example.com/something?query=foo#bar

I think all of these are invalid.

> "The path is terminated by the first question mark ("?") or number sign
> ("#") character, or by the end of the URI."
>
> ==
>
As far as I remember WS/WSS URLs are not sent during the opening handshake.
They can only be used to initiate one.

> (like fragment component)?

As per above, the WebSocket server doesn't need to do this.

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 24 Oct 2011 06:16:36 -0700

Hello Alexey,

> I think all of these are invalid. 

Ok.

> As far as I remember WS/WSS URLs are not sent during the opening handshake. They can only be used to initiate one.

Sorry, what I meant with sending was not the complete WS URL, but the /resource/ component of the WS URL.

That is, what if a WS client starts the handshake with a

GET /something#somewhere/foo HTTP/1.1
Host: example.com
..

Now, what should the server do?

Go on with

/resource/ == "/something"

ignoring the fragment component, or fail the handshake with 400?

---

From: Julian Reschke <[email-masked]>
Date: Mon, 24 Oct 2011 15:28:17 +0200

On 2011-10-24 15:16, Tobias Oberstein wrote:
 > ...

That's an HTTP question; as the

   /something#somewhere/foo

is not a valid rquest-target according to 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#request-target>, 
the server should reject the request with a 400 status.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 24 Oct 2011 23:17:22 +0200

>I think all of these are invalid.

That is what the draft suggests. It seems incorrect to me for the draft
to prohibit using fragment identifiers. Fragment identifiers are not a
scheme-specific feature.
-- 
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/