Here's my code extend ky instance.
ky.extend({
prefixUrl: API_BASE_URL,
headers: {
Authorization: `Bearer ${token}`
}
})
Here's what i've got on network tab request header.

Why did you lowercasing my header key?
HTTP headers are case insensitive.
Yeah but just let the user choose how they're gonna write their headers.
Don't force them to use lowercased headers.
IMHO
Yeah but just let the user choose how they're gonna write their headers.
Is there any reason why? According to the spec it doesn't matter.
I mostly agree with you in principle @rohmanhm. But doing this would actually add some complexity to Ky and I don't think it's worth it given what the spec says.
The reason for the added complexity is that Ky itself is not explicitly lowercasing headers. It's merely a side effect of using new Headers(). Since that's a browser API that we don't control, we'd have to avoid using it to achieve your desired result. I tried removing our usage of Headers in PR #74 (for different reasons) but we ended up keeping it because it turned out to be kind of messy. Also see the discussion here:
That implementation could be made much simpler if we were willing to drop support for a Headers instance in our headers option, but I'm not sure that is the right approach. So unless you can come up with something simpler, I doubt we're going to do this.
Hi,
I stumbled upon this issue while trying to retrieve the same Authorization header from a request response and it took me a few minutes to realize that even though the headers are case insensitive, the response headers getter is not 馃槥:
response.headers.get('Authorization') // returns null
response.headers.get('authorization') // returns the correct value
Do you think an indication could be added in the readme on the fact that Ky lowercases all headers and that retrieving them requires the use of their lowercase name ? (I could create the pr if you like)
(also sorry for digging up a closed issue)
@felixdenoix I'm not against a documentation PR related to this, but it really has nothing to do with Ky. It's because you are using Headers and that's how it behaves. It would be more useful, IMO, to contribute to improving the MDN documentation rather than Ky, and then we can link to it.
Most helpful comment
I mostly agree with you in principle @rohmanhm. But doing this would actually add some complexity to Ky and I don't think it's worth it given what the spec says.
The reason for the added complexity is that Ky itself is not explicitly lowercasing headers. It's merely a side effect of using
new Headers(). Since that's a browser API that we don't control, we'd have to avoid using it to achieve your desired result. I tried removing our usage ofHeadersin PR #74 (for different reasons) but we ended up keeping it because it turned out to be kind of messy. Also see the discussion here:That implementation could be made much simpler if we were willing to drop support for a
Headersinstance in ourheadersoption, but I'm not sure that is the right approach. So unless you can come up with something simpler, I doubt we're going to do this.