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
Case-sensitive header APIs are not usable #1246
Comments
Ah... I think this is something that the Go Thanks for reporting this issue! |
IIRC, HTTP headers are case-insensitive, so if the server strictly checks for lower case only, it's non-compliant. |
Yeah, that's why I put the @meiamsome, can you give us some details about your use case? |
I took a brief look at this, and while the fix itself is straightforward, adding tests for it seems impossible. See 3e3c347. The headers in the request passed to the handler are already transformed to the canonical case used in Go, so we can't write them out in their original case in the response to assert on it. Same goes for the internal httplib endpoints, of course. The fix works though (confirmed with |
Another instance of this problem: https://community.k6.io/t/case-sensitive-headers/2745 The "fix" seems simple, so maybe we should implement it, even if we can't test it? 🤷♂️ And, if we really want to write a test, we can spin up a raw TCP server and parse the raw HTTP request without |
This is not as straightforward as it seems on the surface, so I removed the milestone again... For context, golang/go#5022 (comment) is the very good rationale for why Go doesn't have case-sensitive headers. And that makes complete sense, especially for HTTP servers. However, k6 is a testing tool and there's an argument to be made that artificial restrictions have no place in it. Sending arbitrary case in the HTTP header names is not against the RFC, the RFC just means that servers shouldn't care what the case of incoming header names is... And I'd argue that, even if it was against the RFC, it should be reasonably possible for k6 to even send somewhat malformed HTTP requests. Things like that are a normal part of QA and testing and a testing tool should reasonably accommodate them... 🤷♂️ However, while it's seems like the "fix" on our side is simple, just replace http.get(whatever, {headers: {
'foo': 'bar',
'Foo': 'baz',
}}); It's not clear that it will actually be a bad result, per se, since it will actually allow k6 to send multiple headers with the same header name. We currently can't do that (because we use a JS
So, yeah, I removed the milestone, but I'm not closing the issue either. We're just not rushing to "fix" it before we know the implications. For now, given that there aren't any workarounds to the issues described here, and the fact that so few people have hit them, I'd advise any affected users to comment with their use cases here and 👍 the issue, so we can have more details about the scope and impact of this. In the meantime, you can use xk6 extensions to solve these types of issues for yourself: |
As an additional note the HTTP2 RFC specifies that all header field names MUST be lower case. Which IMO makes fixing this even less relevant as the world moves more and more towards http2. p.s. same is true for HTTP3 at least in the latest draft I could find. |
Since the original issue is that k6 is internally changing the header to some camel-case format, won't you have to fix this to support HTTP2 since it "MUST be lower case"? It seems the better solution would be to leave the headers as is in the script. If an error occurs, the test developers can change the headers to match the requirements for the protocol. As it is now, there is no workaround because k6 is internally changing the headers. Without a workaround, this may eliminate k6 as a viable load testing solution. |
golang's stdlib does this automatically. Otherwise it wouldn't be passing any tests and most servers will have problems with it.
We are aware of this, but the same is true for a lot of the other issues as well. At the moment this seems like a problem for a small percentage of the users, and also a problem that literally will solve itself ... as http1.x becomes less and less common. I am kind of surpised people still have problems with this ... then again we support ntlm, so I guess I shouldn't be. And again - if there was some easy fix with no drawbacks - we would likely have implemented it. Unfortunately it seems like it will be quite involved and likely add more problems than not. |
As requested by @na-- I come in to report an example of a situation in which I ran into the issue:
Further, I also discovered that as soon as one uses
This is the first time in ten years of using the language that I have this "nonsense" feeling about a Go standard API. As a user and a maintainer, I prefer for k6's |
edited☝🏻to reflect my change of opinion regarding the matter. |
We have recently met with the k6 maintainers team to discuss some potential solutions for this. no decisions have been made, and the following is there as information to feed further research and investigation.
|
It is not possible to test a non-conformant HTTP server that is handling headers in a case-sensitive manner. The following example script:
Results in the header being sent as
Lower-Case-Header
, meaning that if the server checks the headers in a case-sensitive manner then the header becomes impossible to set in k6.The text was updated successfully, but these errors were encountered: