search

webspecs / url

The URL specification
https://specs.webplatform.org/url/webspecs/develop/
Other
21 stars 9 forks source link

Added inScope static #22

Closed marcoscaceres closed 9 years ago

rubys commented 9 years ago

I have some minor editorial comments (for example: same origin needs to be spelled out more clearly; and initially it would be based on the definition of origin in this specification). I can take a pass at making these changes, and follow up comments and/or pull requests could be used for further refinements.

If something like CORS is desired, that could also be pursued in a separate issue/pull request.

Given that @annevk has pushed back on the need for this API, can we get a second browser vendor to step forward and express an intent to implement this?

marcoscaceres commented 9 years ago

On Friday, December 26, 2014, Sam Ruby notifications@github.com wrote:

I have some minor editorial comments (for example: same origin needs to be spelled out more clearly; and initially it would be based on the definition of origin https://specs.webplatform.org/url/webspecs/develop/#origin in this specification. I can take a pass at making these changes, and follow up comments and/or pull requests could be used for further refinements.

Sounds good. Thanks for offering to help!

If something like CORS https://fetch.spec.whatwg.org/#http-cors-protocol is desired, that could also be pursued in a separate issue/pull request.

I'm not sure what you mean here? Why would CORS come into play when comparing URLs?

Given that @annevk https://github.com/annevk has pushed back on the need for this API, can we get a second browser vendor to step forward and express an intent to implement this?

Probably need to move this to a larger forum once a concrete proposal is ready. I'm happy to do that once the PR is ready.

— Reply to this email directly or view it on GitHub https://github.com/webspecs/url/pull/22#issuecomment-68106829.

rubys commented 9 years ago

I'm not sure what you mean here? Why would CORS come into play when comparing URLs?

I'm just trying to be thorough. Ruling out CORS makes things simpler, so that's good. Now lets be thorough from the other direction: I'll note that this isn't a byte-for-byte comparison, but rather a comparison of the values of individual URL components after parsing. At the moment, there is still quite a bit of variety as to how user agents parse URLs. At a minimum, this merits a cautionary note. A more aggressive stance would be to return false for all non-conforming inputs. That's still not perfect, but adding more conformance checks may be easier to get consensus on than to get implementation movement towards interop on non-conforming inputs. It is also easier to lift a restriction later than it would be to add one.

Probably need to move this to a larger forum once a concrete proposal is ready. I'm happy to do that once the PR is ready.

I thought this was a concrete proposal. I'm willing to merge it, and then make editorial changes on top of it. The one thing I'm holding on is either an indication that @annevk doesn't object, or an indication that browser vendors will implement this anyway.

marcoscaceres commented 9 years ago

Talked to Anne briefly - will define what I need in my own spec. We can move this stuff down the stack to the URL layer if/when developers require it.