Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

absoluteTo() doesn't work with file:/// ? #328

Closed
CXuesong opened this issue Feb 27, 2017 · 5 comments
Closed

absoluteTo() doesn't work with file:/// ? #328

CXuesong opened this issue Feb 27, 2017 · 5 comments

Comments

@CXuesong
Copy link
Contributor

As far as I know, I can make an absolute URL using the following routine

var rel = new URI("http://example.org/abc");    // Well, not so relative, but I believe it will still works.
rel.absoluteTo("https://abc.xyz/def").toString();

which results in

"http://example.org/abc"

It works fine.

However, when I want to use absoluteTo with file:/// protocol, like this

var rel = new URI("file:///D:/file.txt");
rel.absoluteTo("https://abc.xyz/def").toString();

I get

"https://abc.xyz/D:/file.txt"

instead of

file:///D:/file.txt

Is this a bug, or have I got this wrong? Thank you!

@rodneyrehm
Copy link
Member

The issue is not triggered by or limited to the file:// protocol.

If alpha is a fully qualified URL alpha.absoluteTo(bravo) simply returns alpha:

var rel = new URI("a://b/c?d#e");
rel.absoluteTo("v://w/x?y#z").toString();
// "a://b/c?d#e"

if alpha does not contain an authority alpha.absoluteTo(bravo) simply returns the authority of bravo and the resource of alpha:

var rel = new URI("a:///c?d#e");
rel.absoluteTo("v://w/x?y#z").toString();
// "v://w/c?d#e"

RFC 3986 - 5.2 Relative Resolution explains the algorithm to do this. However, it clearly states that if there is a scheme, the authority of the resolving URL should be used. URI.js on the other hand does a simple merge of all components. This behavior was introduced with a fix for #73 nearly 4 years ago. Given how long this behavior has been in place and you being the first one to stumble over it, I'm wondering if reverting to strict RFC 3986 compliance is the best course of action…

@CXuesong
Copy link
Contributor Author

Thank you for your explanation! I've also taken a look at #158 , and if I got this right, because the authority of some alpha like file:/// is empty, it will be replaced with the authority of bravo according to your reply.

I've to say, this is really a rare case. At least in my situation, I hardly had a chance to process file:///, and if I were to handle such case, I will just check whether the protocol is file:// first. After all, there won't be such a URL like http:///abc.

@rodneyrehm
Copy link
Member

After all, there won't be such a URL like http:///abc.

I've never seen that in the wild. It doesn't mean it doesn't exist, but I consider it much less likely than file:///. This would lead to the conclusion that the resolved URI may only contain bravo's authority if alpha does not contain a scheme.

Do you want to create a patch for this?

@CXuesong
Copy link
Contributor Author

Oh, it's a pleasure! Give me a moment ;-)

CXuesong added a commit to CXuesong/URI.js that referenced this issue Feb 27, 2017
@rodneyrehm
Copy link
Member

thank you! released as v1.18.8

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants