scheme-relative is absolute?

[stevenvachon]

https://github.com/sindresorhus/is-absolute-url/blob/master/test.js#L9

I'd think that it should be false.

[sindresorhus]

Why?

[stevenvachon]

Because //url.com/ means nothing without a base. If its base is http, then it's an http url. If its base is https, then it's an https url. It's a relative url.

[stevenvachon]

Unless those slashes denote an internal network host. In which case, such logic should be toggle-able and probably not default.

See slashesDenoteHost in url.parse()

[sindresorhus]

Hmm, good question. You could argue both ways for it. Yes, it's protocol-relative, but it's still an URL that resolves to an absolute resource, not a relative path.

// @kevva @shinnn @floatdrop @stevemao Thoughts?

[stevemao]

Seems to be an absolute to me but @stevenvachon has a very good argument..

[arthurvr]

Personally I'd go for false but it's just a feeling of mine. Both are valid arguments.

[shinnn]

In this case I expect is-absolute-url to return true.

A new option meets both requirements?

// Just a casual idea

isAbsoluteUrl('//github.com', {includeProtocolRelative: false}); //=> false
isAbsoluteUrl('//github.com', {includeProtocolRelative: true}); //=> true

[stevenvachon]

Also, just look at the name: protocol-relative, scheme-relative.

All URLs resolve to absolute when they have a base URL.

[stevenvachon]

//github.com resolves to https in the browser because the page it's on is used as a base. Taken out of that context, how would it know to resolve to http or https, or even anything else?

If you type //github.com in a browser's address/search field, it looks for a local file.

[sindresorhus]

@stevenvachon It's absolute in the sense that it's not a relative path. What's your use-case needing it to be something different? I think the current behaviour is the most sensible, and unless you have a good use-case, I would say it only needs doc clarification.

[stevenvachon]

Parsing URLs in HTML for example wouldn't know whether to use http or https unless url.resolve() were used.

[sindresorhus]

Hmm...

From Python docs:

If url is an absolute URL (that is, starting with // or scheme://)

But then from StackOverflow:

A relative URL must be either a scheme-relative URL, an absolute-path-relative URL

I guess it makes more sense to follow the latter as it's from the URL Standard.

[stevenvachon]

The URL Standard is split across HTML and URL specs. It's kinda messed up.

[kevva]

Both is correct here imo, but I would expect // to be absolute.

[stevemao]

Maybe this could return undefined?

[kevva]

No.

[stevenvachon]

// isAbsolute(url, slashesDenoteHost);

isAbsolute("//google.com/"); //-> fase
isAbsolute("//localhost/", true); //-> true
isAbsolute("localhost/", true); //-> false

slashesDenoteHost is consistent with url.parse().

[kevva]

Boolean arguments is nasty.

[stevenvachon]

isAbsolute("/google.com/"); //-> isAbsolute.RELATIVE === 0
isAbsolute("http://google.com/"); //-> isAbsolute.ABSOLUTE === 1
isAbsolute("//google.com/"); //-> isAbsolute.PROTOCOL_RELATIVE === 2

also pretty nasty

[stevemao]

I was thinking maybe the return value couldn't be a simple true or false but a enum. So I kinda like @stevenvachon 's solution.

[stevenvachon]

Consider this situation.

[imyller]

// denotes a protocol-relative URL, also called as network-path reference in the spec. Absolute begins with / and relative without slash character.

See my comments at nodejs/node#1790

Point is that io.js does not have any bug and url.resolve behaves as expected.

[kevva]

So, conclusion is that it shouldn't be treated as a absolute URL?

[imyller]

The spec says that

express a URI reference relative to the name space of another hierarchical URI

What happens when another hiararchical URI is not specified. I personally, and in case of Node environment would parse it as local file path; meaning that is actually is badly formatted but functionally valid absolute path (at least in POSIX environments).

But when used with url.resolve it most definitely is not absolute if the spec is followed.

[imyller]

If singular //something is treated as file path, it is not actually valid as it has double slashes, but those are ignored by most OS's.

For reference I just tested with Python os.path.isabs and it also considers //something/something paths as absolute local file paths by returning True

So // has dual nature depending on the context, with a base URL it is not absolute, but without a base URL it can be interpreted as an absolute local path.

[kevva]

The intent of this repo is to check if an URL is absolute so in this case we should return false.

[imyller]

Exactly.

[imyller]

Do note however, that local file paths can also be URL ;)

[imyller]

So if this library chooses it can treat URLs without protocol given as being file:, http:; what ever is the most appropriate. This depends on the environment I think.

For example browsers default to http(s) and local environments often to file.

And then there is the option is to demand a specific protocol for all inputs and fail if its not provided.

[sindresorhus]

@stevenvachon Would you be able to do a doc update for #3?