RPC updates

[tgerring]

Conversion to RPC over HTTP

[tgerring]

Before merging, we should consider rolling in websocket functionality into the rpc package, since the messages and responses should be the same and only the transport is different.

[kumavis]

@tgerring yes this is what we're doing in node-ethereum, http + websocket protocol adapters to a generic rpc handler

[tgerring]

Both traditional HTTP and Websockets should be supported via the updated rpc package. Both transport methods can be started separately as so: ethereum -rpc=true -rpcport=8080 -ws=true -wsport=40404

[coveralls]

Coverage remained the same at 43.13% when pulling a38bca3 on jsonrpc into d792e95 on develop.

[coveralls]

Coverage remained the same at 43.17% when pulling e9d017b on jsonrpc into d792e95 on develop.

[kumavis]

Does the rpc via http handle CORS?

[tgerring]

Is there a specific requirement in terms of enforcing or ignoring CORS? In the linked PR, neither HTTP nor Websocket respect the Origin header. Public-facing integrations will likely want to use a robust proxy such as Apache or Nginx to enforce rate-limiting, etc.

On Jan 27, 2015, at 8:32 PM, aaron notifications@github.com wrote:

Does the rpc via http handle CORS?

—
Reply to this email directly or view it on GitHub.

[kumavis]

@tgerring the browser requires some additional headers for CORS Access-Control-Allow-Origin

[tgerring]

@kumavis HTTP transport has been updated by @obscuren at 7f638f0 setting "Access-Control-Allow-Origin" to "*"

[kumavis]

this is an awesome feature, but I suggest that it should be configurable and off by default, as it exposes the rpc to any website you visit.

[obscuren]

The browser requires it. The browser is useless without. You can configure it (on/off, port). We could add a feature to (dis)allow CORS. Please open new issue.