CORS header stripped from TestRPC response

[chatch]

The browser is rejecting calls to the testrpc server because the header "Access-Control-Allow-Origin: *" is getting stripped off somewhere down the line. Seems nginx is doing this.

I worked around this by bypassing nginx:
testrpc.patch.txt

But maybe there is some tweak to the nginx conf file that will preserve the header?

[gnidan]

testrpc doesn't actually get routed through nginx... the CORS-header stripping is actually a bug with parity-testnet... your solution exposes the port for testrpc if you want to interact with it locally (I wasn't planning on this use case)

@chatch let me know if you want to close this ticket or just rename it to something that more closely reflects the underlying issue (the parity-testnet config, or maybe making nginx expose testrpc)

[chatch]

oh i see. so then i was actually talking to Parity on the web3 init until i changed the docker-compose config! I'll take another look at it with testrpc, i think maybe the answer is to use the container ip address from my dapp rather then localhost. i'll do that and check the cors headers are ok like that.

[gnidan]

How do you feel about exposing testrpc via nginx @chatch? Something like testrpc.ethereum could go in /etc/hosts...

Although CORS probably still needs to get sorted out

[chatch]

Yeah that would be good. I'm not sure if the ip address changes between "docker-compose up" ? If it can stay the same that would be perfect.

I think CORS should be ok so long as the proxy just passes it through. I took a look an testrpc and it adds the header on by default for every response. The reason i wasn't seeing it before was because i was talking to parity! thought i was talking to testrpc.

[gnidan]

Do you use docker-machine? I'm using Docker for Mac, so that doesn't give me a separate IP at all. Which is why I have to use nginx in the first place (no docker0 network available in Docker for Mac)