Bug 80616 - [WebSocket] implement strict URL validator
Summary: [WebSocket] implement strict URL validator
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Depends on:
Blocks: 76198
  Show dependency treegraph
Reported: 2012-03-08 11:17 PST by Takashi Toyoshima
Modified: 2016-05-18 20:44 PDT (History)
6 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Takashi Toyoshima 2012-03-08 11:17:53 PST
In some ports, KURL could not perform strict URL validation, but accept it after performing url escape.
WebSocket should have it own strict URL validator, and use it to raise SyntaxError for invalid URL.

I explicitly added guys to CC
 as WebSocket related committer and reviewer: yutak, bashi, tkent
 as the person who know KURL (FYI): brettw

FYI: https://bugs.webkit.org/show_bug.cgi?id=80172 [Chromium] KURL behaves differently
Comment 1 Kent Tamura 2012-03-08 19:45:12 PST
If we don't have any practical problems/risks with the current implementation, I object to add additional validation check for URLs.
Comment 2 Takashi Toyoshima 2012-03-09 09:49:42 PST
I guess Kent-san think WebSocket specific validator is overkill.
So, how about introducing strict mode in KURL.
Of course, it doesn't mean that I modify KURL interfaces.

Currently, chromium port of KURL doesn't apply strict check for usability and compatibility.
On the other hand, the implementation knows the scheme of provided URL.
My idea is introducing strict validation mode only for ws:// and wss:// schemes implicitly
inside KURL implementation (of chromium port).

WebSocket schemes are newly launched and don't have to keep backward compatibility now.
If we apply lazy validation for WebSocke, we overlooks non-conforming sites.
It could cause the chance of future compatibility issue.

But, basically, I agreed that WebSocket specific another validator is overkill as Kent-san said.
Comment 3 Brent Fulgham 2016-05-18 20:44:09 PDT
It seems like the result of the discussion was that we do not want to take these steps. Please reopen with new information if you feel I am closing this in error.