Add user-agent to default list of Access-Control-Allow-Headers

[sohkai]

Version information:

Mostly to do with public gateways, but issue persists on recent versions:

go-ipfs version: 0.4.13-
Repo version: 6
System version: amd64/darwin
Golang version: go1.9.2

Type:

Enhancement

Description:

When sending requests across CORS, it looks like newer browsers are asking for user-agent in Access-Control-Allow-Headers, and failing fetches without it, e.g.:

It would be really nice if user-agent was included by default in the CORS settings. Also, not sure if setting it twice is the same as a list, but it seems like it should be a list?

See a similar API issue (Github's)

[bpierre]

In the meantime, it should be possible to update the headers using the config file.

[ivan386]

@bpierre Yes it possible. But this setting must be set on all gateways by default.

Firefox block request by XMLHttpRequest to all public gateways without it.

[Stebalien]

I've now merged ipfs/go-ipfs-config#15 so this will be added to the default config. However, due to how our config system works, it won't be applied to existing nodes so I'm not going to close this issue quite yet.

We should either:

1. Add a migration to add this to people's config's.
2. Move these "defaults" out of the config. That is, always apply them regardless of what the user requests. IMO, this may be the best solution as there's no reason to forbid these headers.

As one of our browser experts, thoughts @lidel?

[lidel]

Ok with allowing for user-agent customization during fetch, we want to be compatible with vendor(s) following the spec (whatwg/fetch#37) 👍

• firefox (supported since v43) https://bugzilla.mozilla.org/show_bug.cgi?id=1188932
• chromium (wip@q4-2018) https://bugs.chromium.org/p/chromium/issues/detail?id=571722

As for the cleanup of defaults:

tl;dr I think we should go with (2) AND while at it make sure we will be able to do some cleanup described below.

---

I've looked at our headers recently and started tracking related issues at ipfs/in-web-browsers#132.

As you can see in "go-ipfs v0.4.18 defaults" section of ipfs/in-web-browsers#132 (comment) we already have "hardcoded" defaults for headers such as Access-Control-Expose-Headers.

The need to hardcode support for user-agent out of the box in -Allow-Headers is similar to having X-Chunked-Output in -Expose-Headers (go-ipfs returns it even if not present in config because "it is part of the stack" and without it we are unable to detect streaming responses in js-ipfs-api).

@Stebalien Note that -Allow-Headers and -Expose-Headers control different things (request vs response) and defaults for each should be hardcoded separately, so we can clean them up later (eg. X-Chunked-Output makes sense only in -Expose-Headers).