26253 2014-07-02 19:48:23 +0000 Why is the url attribute of the Request interface a ScalarValueString instead of an URL? 2014-07-07 23:50:11 +0000 1 1 1 Unclassified WHATWG Fetch unspecified PC All RESOLVED WONTFIX P2 normal Unsorted 1 tobie.langel annevk d jaffathecake jungkees mike sideshowbarker+fetchspec oldest_to_newest 108657 0 tobie.langel 2014-07-02 19:48:23 +0000 108658 1 tobie.langel 2014-07-02 19:50:55 +0000 Concerned we're going to see a lot of: var requestURL = new URL(event.request.url); e.g.: https://github.com/jakearchibald/trained-to-thrill/blob/3c6490361e1e373841de3ce8df82a195469be82f/www/static/js/sw.js#L20 108661 2 annevk 2014-07-02 20:46:04 +0000 Maybe. I don't want to return a mutable URL. Maybe something like http://url.spec.whatwg.org/#urlutilsreadonly Or we could offer a asURL() method that returns a new URL object each time. var requestURL = event.request.asURL() 108665 3 tobie.langel 2014-07-02 22:38:37 +0000 (In reply to Anne from comment #2) > Maybe. I don't want to return a mutable URL. Maybe something like > http://url.spec.whatwg.org/#urlutilsreadonly I like the readonly suggestion very much. > Or we could offer a asURL() > method that returns a new URL object each time. > > var requestURL = event.request.asURL() This not so much; It's weird to have a url attribute which needs conversion. On the other hand, URLUtilsReadOnly could have a clone (or toMutable) method that would return a mutable URL instance with the attributes set to the same value as the original one. 108672 4 annevk 2014-07-03 05:36:37 +0000 The asURL() suggestion was with the assumption we would keep url as returning a string. The problem with #urlutilsreadonly is that it's a ton of attributes, including href. 108681 5 tobie.langel 2014-07-03 09:45:49 +0000 (In reply to Anne from comment #4) > The asURL() suggestion was with the assumption we would keep url as > returning a string. Yes. Still. It's weird. > The problem with #urlutilsreadonly is that it's a ton of attributes, > including href. What's wrong with that? (Genuine question.) 108682 6 annevk 2014-07-03 09:51:16 +0000 origin is a direct conflict. href duplicates url. 108684 7 tobie.langel 2014-07-03 10:12:21 +0000 You mean request.headers.get("origin") vs. request.url.origin? 108685 8 annevk 2014-07-03 10:18:38 +0000 (In reply to Tobie Langel from comment #7) > You mean request.headers.get("origin") vs. request.url.origin? I meant request.origin vs request.origin (if we implemented URLUtilsReadOnly on Request). Changing request.url into returning an object of sorts would not match any existing pattern we have for URLs. 108686 9 tobie.langel 2014-07-03 10:46:23 +0000 (In reply to Anne from comment #8) > Changing request.url into returning an object of sorts would not match any > existing pattern we have for URLs. I'm not sure I understand what that means. 108687 10 annevk 2014-07-03 10:52:28 +0000 What we have today is HTMLAnchorElement, HTMLAreaElement, and Location that all implement some variant of URLUtils. We don't have an object that has a property that returns an object that implements some variant of URLUtils. 108688 11 tobie.langel 2014-07-03 11:17:42 +0000 Well, that's one way of looking at it. I see the location object as a property of the window object, so request.url being an immutable instance of URL really doesn't surprise me. (I find it consistant, actually.) 108689 12 annevk 2014-07-03 11:21:03 +0000 Fair. I guess then there's the question as to whether this should be a class or a record as per https://github.com/w3c/screen-orientation/issues/13#issuecomment-47595155 I suspect class since this might become mutable. 108690 13 d 2014-07-03 12:20:03 +0000 I'd like to push back a bit against the OP. I really liked the var requestURL = new URL(event.request.url); pattern when I saw it. It is a good way of having the platform expose (and accept) URLs in a uniform way, as ScalarValueStrings. That makes them easy to work with in various contexts where strings are simpler to work with. And it emphasizes to authors that you can manually construct a URL from any string at any time, when you want to get something mutable and decomposed. But that URL will be separate from the original one; it will be created specifically by you, for you. Indeed, even if we create an immutable URL, people are still going to have to do var requestURL = new MutableURL(event.request.url); in order to get a mutable copy, for the cases where that's what they want. This is already how things are done in Node, as one data point, although they call it `url.parse` instead of `new URL`. --- All that said, if there is strong consensus that you need to design immutable versions of URL, URLSearchParams, etc., then I agree they would be classes, not records. Not because they are likely to become mutable in the future (wouldn't that defeat the entire point?) but because they are likely to have lots of shared behavior (like URLSearchParams's methods which access an internal multimap) in addition to simply storing data. 108694 14 tobie.langel 2014-07-03 13:46:37 +0000 > Indeed, even if we create an immutable URL, people are still going to have to do > > var requestURL = new MutableURL(event.request.url); You could also add a clone method: var requestURL = event.request.url.clone(); But that's a red herring if your plan is to drive people to use strings for URLs as much as possible. In which case, I agree, event.request.url should be a string. I also think new URL(str); instead of URL.parse(str); sends the wrong signal. 108695 15 annevk 2014-07-03 13:52:09 +0000 (In reply to Tobie Langel from comment #14) > I also think new URL(str); instead of URL.parse(str); sends the > wrong signal. If this is the only thing standing from this bug -> WONTFIX. I've asked numerous times for feedback on the URL Standard. Nobody ever came with the argument that new URL(input, base) sends the wrong signal. 108696 16 tobie.langel 2014-07-03 14:15:08 +0000 (In reply to Anne from comment #15) > If this is the only thing standing from this bug -> WONTFIX. I've asked > numerous times for feedback on the URL Standard. Nobody ever came with the > argument that new URL(input, base) sends the wrong signal. Agreed. I had incorrectly assumed the goal of having new URL() was to push devs to use URL objects instead of strings as much as possible. Turns out it's exactly the opposite. In which case, we should close this as WONTFIX and I'll open a bug against the URL standard for favoring URL.parse instead of new URL(). 108697 17 annevk 2014-07-03 14:19:50 +0000 I don't see why we'd ever add URL.parse given new URL is a thing. 108698 18 tobie.langel 2014-07-03 14:33:45 +0000 (In reply to Anne from comment #17) > I don't see why we'd ever add URL.parse given new URL is a thing. Well, I think we have to decide whether we want devs to use URL objects to represent URLs or use Strings instead. If we want URLs to be mostly expressed as Strings, then we want a URL api that consists mostly of static functions (e.g. similar to what exists for JSON). Otherwise, if we want mostly objects, then request.url should return one too. Overall, I'm concerned that we're creating a similar situation as we have between the String constructor and string primitives. But maybe, this just shows a misunderstanding on my part. 108775 19 d 2014-07-07 23:50:11 +0000 (In reply to Tobie Langel from comment #18) > If we want URLs to be mostly expressed as Strings, then we want a URL api > that consists mostly of static functions (e.g. similar to what exists for > JSON). > > ... > > Overall, I'm concerned that we're creating a similar situation as we have > between the String constructor and string primitives. But maybe, this just > shows a misunderstanding on my part. I don't really see this as accurate. Having a structured class representing a mutable URL, versus representing a URL as a string, is a very different situation from having a useless immutable wrapper object (String objects), or stringifying/parsing arbitrary object/array/primitive graphs. URL instances must come from somewhere. In theory they could have a constructor that is e.g. `new URL({ protocol, username, password, host, ... })`, or just `new URL()` (and then you individually set its components). And then `URL.parse` could generate an instance from a string. But in terms of ergonomic API design, I don't see that as a win. It doesn't seem to communicate anything different about how they are supposed to be used, certainly.