ipfs / ipfs-cluster / 3337 / 1
66%
master: 65%

LAST BUILD BRANCH: feat/expvar
DEFAULT BRANCH: master
Ran
Files 67
Run time 11s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 65.784%. First build
3337.1

push

travis-ci

hsanjuan 
Fix #382 (again): A better strategy for handling proxy headers

This changes the current strategy to extract headers from the IPFS daemon to
use them for hijacked endpoints in the proxy. The ipfs daemon is a bit of a
mess and what we were doing is not really reliable, specially when it comes to
setting CORS headers right (which we were not doing).

The new approach is:

* For every hijacked request, make an OPTIONS request to the same path, with
the given Origin, to the IPFS daemon and extract some CORS headers from
that. Use those in the hijacked response * Avoid hijacking OPTIONS request,
they should always go through so the IPFS daemon controls all the
CORS-preflight things as it wants.  * Similar to before, have a
only-once-triggered request to extract other interesting or custom headers
from a fixed IPFS endpoint.  This allows us to have the proxy forward other
custom headers and to catch `Access-Control-Expose-Methods`. The difference is
that the endpoint use for this and the additional headers are configurable by
the user (but with hidden configuration options because this is quite exotic
from regular usage).

Now the implementation:

* Replaced the standard Muxer with gorilla/mux (I have also taken the change
to update the gxed version to the latest tag). This gives us much better
matching control over routes and allows us to not handle OPTIONS requests.

* This allows also to remove the extractArgument code and have proper handlers
for the endpoints passing command arguments as the last segment of the URL. A
very simple handler that wraps the default ones can be used to extract the
argument from the url and put it in the query.  Overall much cleaner this way.

* No longer capture interesting headers from any random proxied request.  This
made things complicated with a wrapping handler. We will just trigger the one
request to do it when we need it.

* When preparing the headers for the hijacked responses:
  * Trigger the OPTIONS request and fi... (continued)

6733 of 10235 relevant lines covered (65.78%)

81.53 hits per line

Source Files on job 3337.1