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
net
in electron7: impossible to set a Host
header in requests
#21148
Comments
@arantes555 Thanks for reporting this issue! We did a bit of digging here to see what the issue was - it looks like this would require a patch to Chromium directly, since this was introduced upstream, but we've added more information to the docs on what headers are restricted and why. If this is a blocker for you, let us know and we can reopen this issue. |
@VerteDinde thanks for your answer ! No, as I said in my original report, I do not consider this to be a critical issue, it is not a blocker for me. It was just a seemingly random breaking change that I couldn't understand when upgrading to electron@7. It's OK to just close it. However, you did mention adding it to the docs, and I cannot seem to find it on the docs for |
@arantes555 Sure thing! I added it to the If you think it would be more helpful somewhere else, though, just let me know, happy to make the change so it's easier to find. |
@VerteDinde Sorry, looks like I missed it yesterday 🤦 It looks like the logical place for that information ! Thanks |
Hi @VerteDinde I would also be happy if we can add |
Preflight Checklist
Issue Details
Expected Behavior
When creating a request with
net
, it should be possible to set theHost
header arbitrarily.Actual Behavior
On electron >= 7, trying to set the
Host
header throws annet::ERR_INVALID_ARGUMENT
error.To Reproduce
Additional Information
When running this, we can see that in electron@6 all requests succeed. On electron@7 however, all requests that set a
Host
header fail with said error.This problem makes it impossible to explicitly set the
Host
, which is normal in a web context, but does not make sensein this case since requests are not done by a webpage.
I feel I have to point out that this one is in not at all a critical issue. It's just that it's a breaking change and that it is a restriction that does not really make sense.
The text was updated successfully, but these errors were encountered: