Sites under public gateways list can't make XHR request

[Kubuxu]

I have site http://bin.kubuxu.ovh, its A records are same as ipfs.io. If I add it to the public gateways list XHR request to /ipfs/[some hash] fails because it is rerouted to local gateway which breaks AJAX somehow. In my case solution would be to redirect site to: http://localhost:8080/ipns/bin.kubuxu.ovh/ then XHR will be allowed to fetch data from /ipfs/....

The solution for this problem might be tricky as for example http://ipfs.pics has to make requests to severs itself (it does not have dnslink).

[lidel]

Indeed: I've put a breakpoint in the error callback of $.ajax request and the err.status() returns rejected (and not much beside that).

We probably need to dig into jQuery internals to understand this better,
perhaps XHR requests require some additional logic.

(For future reference: jQuery used by http://bin.kubuxu.ovh is v1.7.1)

[Kubuxu]

Also the request is not even sent (I Wireshark'ed it).

[lidel]

Ok, I (probably) know what is happening.

Doing XHR request with gateway redirect enabled is effectively doing cross-domain scripting.

Firefox protects users from XSS and executes requests like this only if target server is explicitly configured to accept them. It is indicated via CORS headers and what Firefox does here it to issue OPTIONS request to the gateway to check for them.

I have go-ipfs v0.3.11-dev and it does not support OPTIONS by default:

> curl -X OPTIONS http://127.0.0.1:8080/ipfs/QmRqoVq1G9pL7hyLB2EGi5mndRTQv7tKfFXPRUsSbpHqfK
Method OPTIONS not allowed: read only access

What is more, CORS headers are also missing in gateway responses:

> curl -X HEAD -I http://127.0.0.1:8080/ipfs/QmRqoVq1G9pL7hyLB2EGi5mndRTQv7tKfFXPRUsSbpHqfK
HTTP/1.1 200 OK
Accept-Ranges: bytes
Access-Control-Allow-Headers: X-Stream-Output, X-Chunked-Output
Access-Control-Expose-Headers: X-Stream-Output, X-Chunked-Output
Cache-Control: public, max-age=29030400
Content-Length: 624
Content-Type: text/plain; charset=utf-8
Etag: QmRqoVq1G9pL7hyLB2EGi5mndRTQv7tKfFXPRUsSbpHqfK
Last-Modified: Thu, 01 Jan 1970 00:00:01 GMT
Suborigin: QmRqoVq1G9pL7hyLB2EGi5mndRTQv7tKfFXPRUsSbpHqfK
X-Ipfs-Path: /ipfs/QmRqoVq1G9pL7hyLB2EGi5mndRTQv7tKfFXPRUsSbpHqfK
Date: Fri, 15 Jan 2016 18:05:26 GMT

It is a known issue and was mentioned in ipfs/kubo#1215 (comment) and ipfs/kubo#934 (comment).

So it is not a bug in Addon/Firefox, but the default behaviour of IPFS Gateway. 😧

Running writable gateway with CORS headers is supported by go-ipfs, but you need to enable it manually:

ipfs config --json Gateway.HTTPHeaders.Access-Control-Allow-Methods '["PUT", "GET", "POST"]'
ipfs config --json Gateway.HTTPHeaders.Access-Control-Allow-Origin '["*"]'
ipfs config --json Gateway.HTTPHeaders.Access-Control-Allow-Headers '["X-Requested-With"]'
ipfs config --json Gateway.Writable true

Then restart the daemon.

Sadly, OPTION still does not work:

curl -X OPTIONS http://127.0.0.1:8080/ipfs/QmRqoVq1G9pL7hyLB2EGi5mndRTQv7tKfFXPRUsSbpHqfK

18:45:57.364 ERROR core/serve: Method OPTIONS not allowed: bad request for /ipfs/QmRqoVq1G9pL7hyLB2EGi5mndRTQv7tKfFXPRUsSbpHqfK gateway_handler.go:94

I'll pursue it further, perhaps we need add OPTIONS to gateway_handler.go:80.

[ghost]

I'll pursue it further, perhaps we need add OPTIONS to gateway_handler.go:80.

👍

[lidel]

OPTIONS support fixed upstream.
A related discussion about CORS/XHR support for API is continued in ipfs/kubo#2239