Web3.js: CORS header user-agent in Firefox in 1.0.0-beta.35

Created on 27 Jul 2018  Â·  9Comments  Â·  Source: ChainSafe/web3.js

I am using the new version 1.0.0-beta.35 and I am connecting to a public https provider. Everything works fine in google chrome but when I try it in Firefox he sends Options requests to the public provider which include the following header:

Access-Control-Request-Headers:content-type,user-agent

Google chrome also sends such a header but without user-agent (only content-type). Since I get CORS error on Firefox I googled the problem and it seems quite strange that user-agent gets sent here in Firefox. If I resend the request withouth user-agent it goes through.

In the Firefox console I also see the following Warning:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at XXX. (Reason: missing token ‘user-agent’ in CORS header ‘Access-Control-Allow-Headers’ from CORS preflight channel).

bug

Most helpful comment

Same issue in beta.37.
Is there a known workaround besides downgrading web3 (I have access to the RPC server config)?

PS: may this also be the reason for websocket web3 connections not working in Firefox? I don't get the CORS error messages then, but the request returns 403 (in Chrome it succeeds) and there's headers related to the origin.

All 9 comments

It's not an issue of web3, it's issueabout your config and config of this https provider about header of the HTTP protocol.

I understand that if the provider sends the right CORS this is not an issue, but still the user-agent field in the Access-Control-Allow-Headers is not really common.

The weird thing is if I use the dist/web3.min.js instead of the npm module it doesn't send this header and it works. So I think the problem lies somewhere in how to package your npm module with webpack (which is what I use to package the browser application).

Hey, this's issue!! It makes broken any app of me when I update web3 to .35.

using minified web3 file instead of npm module to temporarily fix bug

It do not fixes this bug, because current minified web3 still .34.

you are using minified web3 of version .34

but still the user-agent field in the Access-Control-Allow-Headers is not really common.

@blacktemplar We're seeing this in requests from Firefox, so it seems like any server application that doesn't include this header would not pass the preflight requests from Firefox? Is that really such a common situation?

downgrade to v1.0.0-beta.33 solved my problem

Same issue in beta.37.
Is there a known workaround besides downgrading web3 (I have access to the RPC server config)?

PS: may this also be the reason for websocket web3 connections not working in Firefox? I don't get the CORS error messages then, but the request returns 403 (in Chrome it succeeds) and there's headers related to the origin.

@nivida any updates on this issue? Seems it's making Brave/Firefox not work with HTTPProvider

I just tried with latest web3 1.0.0-beta.48

Just checked this issue closer and it is a issue of infura. They will fix it with sending of the correct headers. https://github.com/INFURA/infura/issues/174

Was this page helpful?
0 / 5 - 0 ratings