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

Allow input to start with slash by removing head slashes #561

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

jdavidferreira
Copy link

@jdavidferreira jdavidferreira commented Feb 26, 2024

  • Allow input param to start with slash (/) by removing head slashes

@jdavidferreira jdavidferreira force-pushed the allow-input-starts-with-slash branch from 15ef69e to cb89702 Compare February 26, 2024 11:30
package.json Outdated Show resolved Hide resolved
@sindresorhus
Copy link
Owner

From the docs:

Leading slashes in input are disallowed when using this option to enforce consistency and avoid confusion about how the input URL is handled, given that input will not follow the normal URL resolution rules when prefixUrl is being used, which changes the meaning of a leading slash.

@jdavidferreira
Copy link
Author

jdavidferreira commented Feb 26, 2024

From the docs:

Leading slashes in input are disallowed when using this option to enforce consistency and avoid confusion about how the input URL is handled, given that input will not follow the normal URL resolution rules when prefixUrl is being used, which changes the meaning of a leading slash.

I see. Could it be something "discouraged", rather than something "disallowed"? From the little I saw, I don't see how this change could break things in the library. 🙈

@sholladay
Copy link
Collaborator

There's been a lot of discussion on this before in the issues and previous PRs. It's easily the most controversial part of Ky. Basically, it's an opinionated choice meant to make it abundantly clear that the input URL will be appended to the prefixUrl and, more specifically, not resolved against the origin.

FWIW, my stance on this has softened because of how many people complain about it. I'd like to find a way to satisfy everyone.

@fregante
Copy link

While I agree with the relative-vs-root argument, most REST API docs show the endpoints as /something so ky should probably follow suit and maybe even require that.

Those I found that don't follow the format, it's just because they show the full URL (Google APIs, Microsoft APIs)

@sholladay
Copy link
Collaborator

See PR #606 for my proposed solution.

@faradaytrs
Copy link

is there any progress on this?

@sholladay
Copy link
Collaborator

No but it's very much on our radar. I still have a bit of work to do on #606 before it's finalized. When it is ready, I want to discuss which approach is preferred and hopefully merge one or the other. I like having both PRs to look at so the discussion is less abstract.

@bertho-zero
Copy link
Contributor

bertho-zero commented Oct 30, 2024

I prefer this PR to #606, just remove that if which doesn't really provide the protection it thinks it does.

Workaround: .replace(/^\//, "") everywhere

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

Successfully merging this pull request may close these issues.

6 participants