Parity GUI error (getTransactions TypeError: Failed to fetch)

Question

I'm running a parity peer connected to a custom blockchain (PoA), but I can't send a transaction, nor see the list of transactions of my account. I get the following errors (see error screenshot):

• No 'Access-Control-Allow-Origin' header is present on the requested resource.
• 406
• getTransactions TypeError: Failed to fetch

The errors points to a CORS problem, but all configurations I tried for cors ("all", "null", "*", "none", "http://example.com:8540") led to the same result. I get the same result both when running the peer locally and when running it remotely accessing the GUI from my pc. All listed ports are opened in the firewall. Chrome extensions are disabled; tried also in incognito mode. I also tried adding the command line option --unsafe-expose to no avail.

Here is my toml on the remote machine (running Ubuntu):

[parity]
chain = "pcplExternal.json"
base_path = "/home/mike/parity"
[network]
port = 30303
[rpc]
hosts = ["all"]
port = 8545
interface = "0.0.0.0"
cors =["all"]
apis = ["web3", "eth", "net", "personal", "parity", "parity_set", "traces","rpc", "parity_accounts"]
[ui]
force = true
port = 8540
interface = "0.0.0.0"
path = "/home/mike/parity/signer"
[websockets]
origins = ["all"]
apis = ["web3", "eth", "pubsub", "net", "parity", "parity_pubsub", "traces", "rpc", "shh", "shh_pubsub", "personal", "signer"]
hosts = ["all"]
port = 8450
interface = "0.0.0.0"

Any idea what goes wrong?

Eschatology

You likely don’t have any CORS problems. It seems the problem you need to fix is whatever’s causing the 406 error. If you fix that, you’ll likely find your CORS config is actually already working as expected — because, if the server is like most other web servers, it’s expected it won’t add CORS response headers to 4xx or 5xx error responses. Most web servers by default only add user-configured headers to 2xx success responses. So if something’s happening on the server side that’s causing your server to respond with a 406, it’s somewhat expected you’ll see a CORS error message in the browser. – Compurgation

I don’t know under what conditions the web server involved here will send by back 406 HTTP status code in a response, but servers usually do that to they can’t send back the kind of response that the client requested. For example, if your client code is adding an Accept header with, say, and application/json value but the server isn’t capable of sending an application/json response, then sending back a 406 would be one way to indicate that. You’d need want to check the server logs to see if the server’s logging any internal message about what led to the 406. – Compurgation

To be clear, it seems very unlikely your CORS configuration is causing the server to respond with a 406. In server that properly handles the CORS protocol in conformance with relevant spec requirements, the only effect that enabling CORS support should have is to cause the server to send back additional response headers. That’s it. Enabling CORS support should otherwise never cause the server to reject particular requests or to respond to them with a different status code or to do any additional checking of the Accept request header or really any request header than maybe the Origin header. – Compurgation

All the above said, one key requirement to understand is that the server must properly respond to OPTIONS requests (not just GET & POST or whatever your client code itself is sending) — it must respond to OPTIONS request with a 2xx. That’s because as part of the CORS protocol, browsers sometimes (often) automatically on their own send a “preflight” OPTIONS request. See developer.mozilla.org/en-US/docs/Web/HTTP/CORS for the details. So I guess one thing’s that possible is, that 406 from your server might be a response to an OPTIONS request. But is so, the server’s not designed right. – Compurgation

Answer 1

This is a bug in the Parity User Interface and/or the Etherscan API.

If you look closely in your screenshot, it says "Transaction List Powered By Etherscan", this is not related to your node configuration in first place. Background is, that a full node cannot easily provide you with a transaction list for your account.

Also, unrelated but still important; since you are running a private network, Etherscan simply does not have your data.

Note, I'm working for Parity.

Crag