This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23523 - Setting Location protocol throws on invalid protocol
Summary: Setting Location protocol throws on invalid protocol
Status: RESOLVED MOVED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: URL (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: Unsorted
Assignee: Anne
QA Contact: sideshowbarker+urlspec
URL:
Whiteboard: blocked on refactoring
Keywords:
Depends on: 23463
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-15 15:17 UTC by Erik Arvidsson
Modified: 2015-08-14 11:59 UTC (History)
3 users (show)

See Also:


Attachments

Description Erik Arvidsson 2013-10-15 15:17:00 UTC
All browsers agree that setting location.protocol to an invalid protocol throws.

However, only IE throws when setting HTMLAnchorElement protocol.
Comment 1 Anne 2014-01-14 11:11:00 UTC
I cannot reproduce this. If I paste

<script> try { location.protocol = "https" } catch(e) { w(e)} </script> 

into

http://software.hixie.ch/utilities/js/live-dom-viewer/

it is not logging an exception.
Comment 2 Erik Arvidsson 2014-01-14 15:29:37 UTC
(In reply to Anne from comment #1)
> I cannot reproduce this. If I paste
> 
> <script> try { location.protocol = "https" } catch(e) { w(e)} </script> 
> 
> into
> 
> http://software.hixie.ch/utilities/js/live-dom-viewer/
> 
> it is not logging an exception.

How is "https" an invalid protocol?

location.protocol = 'x y z'

SyntaxError: Failed to set the 'protocol' property on 'Location': 'x y z' is an invalid protocol.
Comment 3 Anne 2014-01-15 10:29:51 UTC
My bad. It's not entirely clear how I can write this into the specification with the current setup. I can observe scheme not having changed, but that does not necessarily mean the input was invalid (it could be the same scheme).
Comment 4 Anne 2014-05-22 12:57:56 UTC
Simon, once you implement the API in Rust you want to take this into consideration.
Comment 5 Anne 2015-06-16 11:29:42 UTC
Gecko also throws when setting it to an "unknown" scheme, definition of "unknown" unclear.

It's not entirely clear to me what Chrome does when setting it to e.g. "x" for instance. It seems to not throw, but also not change the scheme.
Comment 6 Anne 2015-06-16 18:14:13 UTC
Two ways of addressing this in the specification:

1. We make the URL parser return failure even for state override invocations.
2. We create an algorithm specifically for parsing the scheme.

1 should be pretty easy.
Comment 7 Anne 2015-08-13 08:57:15 UTC
1 is complicated by the checks that do not allow you to change from a special scheme to a non-special scheme and vice versa, which we want for <a>, <area>, and URL.

It seems for Location however, that should not throw, but should likely also not result in a scheme change. (Scheme change seems mostly relevant for "http" -> "https".)

We could of course sometimes return failure and sometimes terminate steps (equivalent to returning void in IDL terms). A bit confusing perhaps, but it would result in what we want here.
Comment 8 Anne 2015-08-14 11:59:42 UTC
Thank you for the report. Digging into this further I discovered that Location works all kinds of incorrectly if we put it logically on top of URLUtils. I filed https://github.com/whatwg/url/issues/61 which we'll use to get this sorted out.