Allow leading slash behavior with opt-in

[rien]

What problem are you trying to solve?

I personally experience the disallowed leading slash to be confusing and not ergonomic. Mainly because I'm used to this behavior being accepted in other HTTP clients. I understand why it's not desired to allow this by default, but I would like to opt-in to this behavior.

Describe the feature

A simple flag allowLeadingSlash: boolean (default true) which would allow leading slashes.

Normal usage:

const instance = got.extend({ prefixUrl: "http://localhost:3000", allowLeadingSlash: true });
const response = await instance.get("/test");
// http://localhost:3000/test

If the prefixUrl already contains a path, we just append to it:

const instance = got.extend({ prefixUrl: "http://localhost:3000/api/", allowLeadingSlash: true });
const response = await instance.get("/test");
// http://localhost:3000/api/test

Internally this could work by stripping any leading slashes in the input if this flag is set, or by ignoring the slash and just appending it. This will cause ugly, but still valid (and equivalent) URL's like http://localhost:3000//test and http://localhost:3000/api//test.

Checklist

• I have read the documentation and made sure this feature doesn't already exist.

[sindresorhus]

Mainly because I'm used to this behavior being accepted in other HTTP clients.

That's not a strong argument.

Also, Got follows the web API's, which is the most popular HTTP client. foo is relative, /foo is absolute.

A simple flag allowLeadingSlash: boolean (default true) which would allow leading slashes.

Every new option adds overhead, both to the implementation, testing, docs, etc, but also to the user. They have to read the docs for every option and understand what it does, and then evaluate if it's something they need.

[rien]

Thank you for your response, I appreciate your input.

Mainly because I'm used to this behavior being accepted in other HTTP clients.

That's not a strong argument.

I think we disagree on that. There are also a few other people who find this behavior not intuitive (here and here).

Also, Got follows the web API's, which is the most popular HTTP client. foo is relative, /foo is absolute.

Isn't /foo relative to the root? If that is the desired behavior then I can extend the PR to have this behavior if you want, however that would add more overhead to the implementation like you say.

According to the web API, multiple slashes are allowed after each other. So allow me to counter by saying that is not a strong argument either ;)

Every new option adds overhead, both to the implementation, testing, docs, etc, but also to the user. They have to read the docs for every option and understand what it does, and then evaluate if it's something they need.

I certainly agree on this, but the added code and documentation is small. The return in flexibility and human-friendliness is worth the minimal increase in overhead in my humble opinion.

That being said, it is your project and I'm very grateful for your time and dedication that went into it, so I would definitely understand if you would not want this feature. It is not my intent to force this onto the project, I simply thought this would be a useful extension to an already great project.

[szmarczak]

This has been already discussed and the situation won't rather change. Duplicate of #562 #783

[swang2019]

i think this is a good design like the old request module designs.

path merge to baseUrl and it also allow call prefixUrl itself. as currently in got, once you set the prefixUrl it does not seems like you can call itself without supply another subpath