Bug 80616
| Summary: | [WebSocket] implement strict URL validator | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Takashi Toyoshima <toyoshim> |
| Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | Normal | CC: | ap, bashi, bfulgham, brettw, tkent, yutak |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | |||
| Bug Blocks: | 76198 | ||
Takashi Toyoshima
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
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Kent Tamura
If we don't have any practical problems/risks with the current implementation, I object to add additional validation check for URLs.
Takashi Toyoshima
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.
Brent Fulgham
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.