ky: Unhandled Rejection (Error): `input` must not begin with a slash when using `prefixUrl`

Hi,

I receive this exception when trying to call an API resource at https://example.com/foo/id

My ky instance is created as follow:

import ky from 'ky';

const config = {
    prefixUrl: process.env.API_ENTRYPOINT,
    headers: {
        'accept': 'application/ld+json'
    }
};

export default ky.extend(config);

I read the discussion related to the #11 and especially the one you wrote https://github.com/sindresorhus/ky/pull/11#issuecomment-424838175

Sorry to be rude, but I disagree with the choice you made. From my point of view, the only acceptable format should be await ky('/unicorn', {prefixUrl: 'https://cats.com'});.

It is not a matter of taste, just a choice guided by the RFC3986: As per the section 3.3:

If a URI contains an authority component, then the path component must either be empty or begin with a slash (“/”) character.

For the url https://cats.com/unicorn we have the following parts:

The scheme: https
The : separator
The authority //cats.com (no userinfo, no port and host=cats.com)
The path to the resource: /unicorn

Except if the path is empty, a path must start with a slash.

Can you please reconsider the choice you made in #11 and modify this library according to that RFC?

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 17

Most upvoted comments

This error is totally nuts and completely insane, forward slash at the start of the resource path is 100% and COMPLETELY valid.

Lack of a forward slash can introduce problems when it comes to relative URL’s.

Using a forward slash works fine when urlprefix is not defined, and that is indeed what I want in production, but in development I cannot proxy requests to the express server, and I therefore I need to use the prefixurl which in turn would require the production-ready resource-paths to be broken by insisting on them not beginning with a forward slash.

So what, am I supposed to keep two sets of api endpoints? One for development, and one for production, only differing by a forward-slash?, all because of your narcissistic desire to control something so trivial?

Please fix this.

aintHuman on May 8, 2020

If ky were unopinionated, it would implement browser URL resolution, and your requests would still go to an incorrect URL, as I described above, because you are treating origin relative URLs as though they are resource relative, which is going to break on basically any sane library.

I am hopeful that we can take care of this part of my last comment though:

I do see how it’s inconvenient that we don’t support origin relative URLs when using an extended ky instance with a prefix. That feels like a genuine problem to me.

Anyway, I’m glad you’ve got something that works for you. I hope this was still useful in some way. 😃

sholladay on Jan 4, 2019

The simple answer is that if you want to reach https://api.example.com/books while using a prefix, then your prefix should be https://api.example.com and your input should be books.

await ky('books', { prefixUrl : 'https://api.example.com' });

If you want to reach https://api.example.com/books/1234 while using a prefix, then your prefix can be either https://api.example.com or https://api.example.com/books.

await ky('books/1234', { prefixUrl : 'https://api.example.com' });
await ky('1234', { prefixUrl : 'https://api.example.com/books' });

As an aside, your prefixUrl can optionally end with a slash, Ky will behave the same regardless.

Right now, to reach https://api.example.com/books/ (note the trailing slash), you could even do this:

await ky('', { prefixUrl : 'https://api.example.com/books' });

We could probably change that to not append the trailing slash if input is empty. But I’m not sure it’s worth it. Some people would probably prefer the old behavior. I think it would be better for users to instead use a prefix with one less path component and then use a more explicit input that includes or excludes the trailing slash, if it matters to the server.

sholladay on Jan 3, 2019