Interop Tests for HTTP Gateway

[lidel]

This is meta-issue to discuss creation of interop tests for HTTP Gateway.

Goals

• ensure GO and JS are implementing HTTP semantics in the same way
• empower public gateway owners with a quick way to verify they did not break anything
  (via misconfigured Nginx running in front of ipfs daemon etc)
  • should be possible to point test suite at a public gateway and test it for expected default behaviors

What to test?

Areas that we need to test:

• CORS
• HTTP Caching semantics (IPNS vs IPFS)
• DNSLink support
• Range requests
• Content-type sniffing
• Behavior around path vs subdomain gateway (when we support it natively – Act as HTTP PROXY for http://<cidv1b32>.ipfs.localhost kubo#5982)
• Mandatory redirect when directory URL does not end with slash (infura disabled it: relative links in files not added ipfs-shipyard/ipfs-deploy#86 (comment))
• <what else?> (comment below)

I'll be happy to seed the interop test suite with tests for historical issues: been collecting quirks around HTTP headers in ipfs/in-web-browsers#132.

---

I imagine maintenance, browsers and gateway as a product groups would be interested in having something like this (cc @hsanjuan @lanzafame @olizilla @jimpick @hugomrdias @autonome @Stebalien @alanshaw).

Kick-off question: should it live in ipfs/interop as test:gateway or in a separate repo?

[alanshaw]

I'd be fine with them living here, they should run by default with npm test, if you want to setup a script for just running the gateway tests then that's also fine.