feat: gateway subdomains + http proxy mode #6096

Stebalien · 2019-03-18T17:09:49Z

Depends on ipfs/go-ipfs-config#30

TODO: Needs base32 peer IDs. The IPNS and p2p proxy stuff doesn't currently work due to this.
Think through the "known gateway" concept.

What does this do?

Any HTTP CONNECT (proxy) requests will be looped backed to the gateway. This means a browser can, e.g., proxy http://ipfs.io/ipfs/... to the local gateway without redirecting (or touching the URL bar).
IPFS can handle CIDs in subdomains. That is, http://CID.ipfs.localhost:8080.

fixes #5982
fixes #6498
cc ipfs/in-web-browsers#89, ipfs/ipfs-companion#667

lidel · 2019-07-16T21:28:50Z

I'm trying to look at this by the lens of what potential user wants.
AFAIK simplified Gateway use cases are:

(A) run go-ipfs on local machine with default settings
(B) run Path Gateway on some hostname
(C) run DNSLink Gateway for some|single domain with proper DNS TXT record
(D) set up Subdomain Gateway on some hostname

I think (A) should be "batteries included" and not require any configuration, (D) requires more advanced setup in DNS anyway, so it is ok for it to be an opt-in, and there is some vagueness about resolution rules when (B) and (C) happen to use the same hostname, which suggests there should be a way to make both configurable or simply do not allow that scenario on a single hostname.

Having that as a starting point, some notes below (apologies, I failed to make this shorter).

Simplify configuration of Gateway features

I like the idea of having explicit list of hostnames that impacts the way requests are handled, but we should not hardcode any known PublicGateways: we want people to run their own. Let's keep the list empty and dogfood entire configuration process on our gateways.

Would it be more versatile and easier to reason about if we tweak ipfs/go-ipfs-config#30 and add three clear options to control gateway behavior?

Something like (names are just placeholders):

Gateway.DNSLink – optional boolean to control DNSLink support (default: true)
Gateway.SubdomainHosts – optional array of hostnames whitelisted for use in subdomains and proxy mode (+ implicit localhost)
Gateway.PathHosts - optional array of hostnames that are known to be path-based Gateways where content paths should take priority over DNSLink (+ implicit 127.0.0.1 and ::1)

Caveats:

These config options replace UseSubdomains and PublicGateways
Every hostname on Gateway.SubdomainHosts needs to redirect non-subdomain paths (dweb.link/ipfs/<cid>/foo) to subdomain ones (<cid>.ipfs.dweb.link/foo)
There needs to be some validation that ensures SubdomainHosts and PathHosts have no overlap or ignore hostnames that are on both
If we don't allow DNSLink+Path Gateway on the same hostname (and handle ipfs.io via Nginx) the Gateway Heuristic below get MUCH easier, and I think we no longer need PathHosts

Gateway Heuristic

Localhost

IIUC there is a golden path for localhost:

Support <cid>.<ns>.localhost out of the box
(localhost as a permanent, implicit entry on Gateway.SubdomainHosts)
requests to localhost hostname (without subdomain) need to be redirected to 127.0.0.1 (same path, but on raw IP). This will ensure the Origin(s) of Path and Subdomain gateways on a local machine are separate (and users can have both!)

Public Gateways

I feel I am missing some context on gateway symlinks mentioned here – what are use cases for that?

So far I was under impression that mixing namespaces such as DNSLink website with Path Gateway is something we want to move away from. It makes security model unnecessarily hard to reason about and I did not see any use in production apart from ipfs.io (which we want to move to dweb.link anyway).

That being said:

If we allow Paths & DNSLink on the same hostname

We use Gateway.PathHosts to control which hostnames prioritize Path Gateway over DNSLink.
Default use case is hosting websites with DNSLink. DNSLink takes a priority unless gateway hostname is listed in Gateway.PathHosts:

IF Host is matching <cid>.<ns>.example.com and example.com is listed in Gateway.SubdomainHosts
THEN process request as Subdomain Gateway
ELSE
- IF path is /ipfs/, /ipns/ or /api/
  - IF example.com is listed in Gateway.PathHosts
    THEN process request as Path Gateway
  - ELSE
    - IF Host is not IP and DNSLink is present
      THEN process request as DNSLink
    - ELSE process request as Path Gateway
- ELSE process request as DNSLink or return 404

If DNSLink always takes a priority

We don't need Gateway.PathHosts and it gets much easier:

IF Host is matching <cid>.<ns>.example.com and example.com is listed in Gateway.SubdomainHosts
THEN process request as Subdomain Gateway
ELSE
- IF Host is not IP and DNSLink is present
  THEN process request as DNSLink
- ELSE process request as Path Gateway

Personally I'd like to keep it simple and avoid mixing DNSLink with Path Gateway if possible,
but let me know if I missed any nuance.

Configuration Examples

DNSLink

Gateway.DNSLink = true
Gateway.SubdomainHosts = []
Gateway.PathHosts = []

example.com/foo will load via DNSLink (if present)
example.com/ipfs/foo will load via DNSLink (if present)
<cid>.ipfs.example.com/foo will return 404 Not Found

Path Gateway

Gateway.DNSLink = true
Gateway.SubdomainHosts = []
Gateway.PathHosts = ['example.com']

example.com/foo will load via DNSLink (if we allow mixing with DNSLink)
example.com/ipfs/<cid> will load via Path Gateway
<cid>.ipfs.example.com/foo will return a 301 redirect to example.com/ipfs/<cid>/foo

Subdomain Gateway

Gateway.DNSLink = true
Gateway.SubdomainHosts = ['example.com']
Gateway.PathHosts = []

example.com/foo will load via DNSLink (if we allow mixing with DNSLink)
example.com/ipfs/<cid>/foo will return a 301 redirect to <cid>.ipfs.example.com/foo
<cid>.ipfs.example.com/ will load via Subdomain Gateway

Thoughts?

Stebalien · 2019-12-19T11:22:47Z

Unless I'm mistaken, I believe our proposals are mostly isomorphic. PublicGateways isn't the list of all public gateways that exist, it's the list of public gateways that the go-ipfs proxy will handle.

We might want a better name.

Given:

{
  SubdomainHosts: ["x"],
  PathHosts: ["y"],
}

This would be expressed in the current patch as:

{
  PublicGateways: {
    "x": {
      "UseSubdomains": true,,
      "PathPrefixes": ["/ipfs", "/ipns"],
    },
    "y": {
      "UseSubdomains": false,
      "PathPrefixes": ["/ipfs", "/ipns"],
    },
  }
}

The benefits of doing it this way are:

No chance of conflicting rules.
We can add flags as we add optional features to gateways. (not a strong motivation)

There needs to be some validation that ensures SubdomainHosts and PathHosts have no overlap or ignore hostnames that are on both

That's why I had a single list.

If we don't allow DNSLink+Path Gateway on the same hostname (and handle ipfs.io via Nginx) the Gateway Heuristic below get MUCH easier, and I think we no longer need PathHosts

There's still an issue of hosting a DNSLink website and a subdomain gateway on the same hostname. In the original proposal, we'd redirect paths listed in PathPrefixes to the subdomain gateway.

I feel I am missing some context on gateway symlinks mentioned here – what are use cases for that?

With symlink support, any DNSLink website could become a "gateway" by creating a symlink to /ipfs. The go-ipfs gateway would.

Lookup the dnslink record for the website.
Resolve the website's IPFS directory.
Lookup /ipns/my.domain/ipfs/...
See that /ipns/my.domain/ipfs is actually a symlink to /ipfs.
Serve /ipfs/...

So far I was under impression that mixing namespaces such as DNSLink website with Path Gateway is something we want to move away from. It makes security model unnecessarily hard to reason about and I did not see any use in production apart from ipfs.io (which we want to move to dweb.link anyway).

In general, we do. However, users may still want to have path-based gateways (possibly with javascript disabled via CSP) with a nice homepage.

Stebalien · 2019-12-19T11:23:44Z

Gateway.DNSLink – optional boolean to control DNSLink support (default: true)

This should definitely be an option.

Stebalien · 2019-12-19T11:24:33Z

What if we replace the boolean DNSLink with a third, optional list (catch-all if list is empty or missing)?

Good point.

Stebalien · 2019-12-19T11:25:40Z

Thinking about it a bit, I like the way you've split the gateway lists (path/subdomain). I'm just not entirely sure how to handle subdomain gateways + dnslink + redirects.

lidel · 2019-12-30T15:37:58Z

`dweb.link`: all-in-one gateway edge case

I'm just not entirely sure how to handle subdomain gateways + dnslink + redirects.

Our dweb.link makes a good test case for this, so let's look at it as an example.

I believe the setup we want is:

subdomain gateway at {cid}.ipfs.dweb.link
path gateway at dweb.link/ipfs/{cid} that redirects to {cid}.ipfs.dweb.link
DNSLink website at dweb.link with info about what IPFS gateway is etc
convention over configuration, where possible

If we agree on the above, then we see there is only one way to handle the "fallback order":

enabling subdomain gateway implicitly enables redirects from dweb.link/ipfs/{cid} to {cid}.ipfs.dweb.link
- this gives us backward-compatibility with existing tools that accept a URL of "IPFS gateway" without the need for differentiating between subdomain and path based ones
  (examples: IPFS Companion, MetaMask, {a browser vendor})
- this means "subdomain > path > dnslink"
  - subdomain takes priority over path
  - path-based gateway at dweb.link/ipfs/{cid} takes priority over DNSLink for dweb.link

Different take on the config

I like how your version enables us to add more configuration options per hostname.
It is not a strong motivation today, but makes things much more flexible and could save us a lot of headache in the future. Worth considering.

@Stebalien How does the below convention look like?

"Gateway": {
  "Hostnames": {
    "dweb.link": {
      "ResolveSubdomains": true
    },
    "ipfs.io": {
      "ResolvePaths": true,
    },
    "en.wikipedia-on-ipfs.org": {
      "ResolveDNSLink": true
    }
  }
}

The same as above, but with explicit default values:

"Gateway": {
  "ResolveDNSLink": true, /*implicit*/
  "Hostnames": {
    "127.0.0.1": { /*implicit*/
      "ResolveSubdomains": false,
      "ResolvePaths": true,
      "ResolveDNSLink": false
    },
    "::1": { /*implicit*/
      "ResolveSubdomains": false,
      "ResolvePaths": true,
      "ResolveDNSLink": false
    },
    "localhost": { /*implicit*/
      "ResolveSubdomains": true,
      "ResolvePaths": false,
      "ResolveDNSLink": false
    },
    "dweb.link": {
      "ResolveSubdomains": true,
      "ResolvePaths": false, /*implicit*/
      "ResolveDNSLink": true
    },
    "ipfs.io": {
      "ResolveSubdomains": false, /*implicit*/
      "ResolvePaths": true,
      "ResolveDNSLink": true
    },
    "en.wikipedia-on-ipfs.org": {
      "ResolveSubdomains": false, /*implicit*/
      "ResolvePaths": false, /*implicit*/
      "ResolveDNSLink": true
    }
  }
}

Note:

localhost gateways are implicit and enabled by default
- IP ones are path-based
- localhost domain is used for subdomains
- we need both types to work: IPFS Companion will detect OS support for localhost subdomains and enable it as the default
ResolveSubdomains takes priority over ResolvePaths if both are true. Path redirect to Subdomain is always present (even if ResolvePaths: false)

Stebalien · 2020-01-03T21:57:37Z

@lidel LGTM! Go for it.

alanshaw · 2020-01-07T00:44:28Z

My only issue with this format is that for most people the default config will be correct and so the host config for each host will just be an empty object.

Maybe we could drop the word "Resolve" from "ResolvePaths", "ResolveDNSLink" etc.?

Otherwise this LGTM!

lidel · 2020-01-23T15:18:57Z

gateway: localhost subdomains with cid conversion

- "known gateways" can be now defined with or without port.
  if port is missing, a version defined without it will be used
  as a fallback
- subdomain gateway at *.ipfs.localhost is supported out of the box
- subdomain gateway redirects path-gateway requests to subdomain version
  with automatic conversion to CIDv1 in Base32
  (try http://localhost:8080/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR)

Initial success with *.ipfs.localhost working out of the box (regular gateway, not proxied).

Next steps:

Some fun screenshots

Note: Crossed padlock is Firefox-specific waiting for upstream fix, as noted in https://bugzilla.mozilla.org/show_bug.cgi?id=1220810#c23

IPFS CIDv1:

DNSLink websites:

Even ENS looks cool:

Stebalien

Looking nice.

docs/config.md

lidel · 2020-01-30T16:52:41Z

Updated Gateway config and Gateway.PublicGateways examples:
https://github.com/ipfs/go-ipfs/blob/feat/gateway-subdomains/docs/config.md#gatewaypublicgateways

The time for 🚲🏚️ is NOW ;-)

Stebalien

Review of the config documentation only. From what I can tell, the design looks good. I assume most of my comments are just bugs.

docs/config.md

lidel · 2020-02-11T22:49:41Z

(rebased and updated docs/config to match new style from #6855)

Next: finish writing tests (proxy+dnslink)

core/corehttp/gateway_proxy.go

test/sharness/lib/test-lib.sh

namesys/routing.go

namesys/namesys.go

This switches to peer.Decode as suggested in #6096 (comment) and adds tests for missing PeerID types. License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

Stebalien · 2020-03-17T21:38:38Z

namesys/routing.go

-		close(out)
-		cancel()
-		return out
-	}


We should probably have a test for this case as well.

I don't remember removing this on purpose, we should restore this.

Digression: I'd do it myself but I need to fix my go dev env, go-ipfs requires go 1.14 now, and on my OS that requires kernel > 5.2 due to a known bug (golang/go#37436), so need to upgrade a few things 🙃
(commenting so we don't forget)

core/corehttp/hostname.go

Stebalien · 2020-03-18T00:54:36Z

core/corehttp/hostname.go

+	// Example: given "dist.ipfs.io.ipns.dweb.link":
+	// 1. Lookup "link" TLD in knownGateways: negative
+	// 2. Lookup "dweb.link" in knownGateways: positive
+	for i := range labels {


for i := len(labels) - 1; i >= 2; i-- { ... }

I've pushed a patch for this.

Stebalien · 2020-03-18T01:03:42Z

core/corehttp/hostname.go

+	if err == nil {
+		return host
+	}
+	// noop: this should never happen


How so? There may not be a port.

(we're implementing an _actual_ proxy) License: MIT Signed-off-by: Steven Allen <steven@stebalien.com>

Instead of adding a new fake header (that could be spoofed by the client...), just read the original request URI from the request object. This also removes support for suborigins. They have never been implemented in browsers and it looks like efforts have stalled. We can add support back if we need it but, well, maintaining support was going to be more trouble than it was worth. License: MIT Signed-off-by: Steven Allen <steven@stebalien.com>

Allows static DNSLink mappings with IPFS_NS_MAP. License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

Stebalien · 2020-03-18T02:43:53Z

I've squashed this into reasonable commits.

Stebalien · 2020-03-18T02:44:42Z

And I've updated go-ipfs-config to the release version.

core/corehttp/hostname.go

lidel · 2020-03-18T14:15:29Z

namesys/routing.go

-		close(out)
-		cancel()
-		return out
-	}


I don't remember removing this on purpose, we should restore this.

Digression: I'd do it myself but I need to fix my go dev env, go-ipfs requires go 1.14 now, and on my OS that requires kernel > 5.2 due to a known bug (golang/go#37436), so need to upgrade a few things 🙃
(commenting so we don't forget)

License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

When request is sent to http://localhost:8080/ipfs/$cid response has HTTP 301 status code and "Location" header with redirect destination at $cid.ipfs.localhost:8080 Redirect is followed by browsersi, but not by commandline tools. Status 301 is ignored by curl in default mode: it will print response and won't follow redirect, user needs to add -L for that. To fix curl, we return correct payload in body of HTTP 301 response, but set Clear-Site-Data header to ensure Origin sandbox can't be abused. This requires a surgical workaround: If Location header is present in ResponseWriter's Header map, we ensure http.ServeContent() returns HTTP 301 Context: #6982 License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

…o account

lidel

Approving because @Stebalien can't approve PR he initially created 🙃

Stebalien · 2020-03-18T16:06:38Z

ilyaigpetrov · 2020-03-18T16:33:18Z

I can't wrap my mind around this currently, so I just kindly ask you not to forget the idea of @Stebalien about permanent links if it's appropriate here:

In that light, we may want something like https://<ipns-hash>.ipns-archive.cf-ipfs.com/<signed-ipns-record>/.... Or maybe the query string? https://<ipns-hash>.ipns.cf-ipfs.com/thing/other-thing?backup=<signed-ipns-record>?

Source: ipld/specs#19 (comment)

If it's not appropriate, just ignore me.

Stebalien · 2020-03-18T17:03:10Z

This change won't conflict with that feature.

ilyaigpetrov · 2020-03-19T14:51:57Z

This change won't conflict with that feature.

In the screenshots above I see *.ipns.localhost:8030 so if we request <ipns-hash>.ipns.localhost:8030/<signed-ipns-record>/baz/file then there would be a conflict with files served from FS and <signed-ipns-record>.

Could you, please, elaborate why won't there be a conflict: will be this service launched on special port (e.g. 8030) different from permanent mutable links?

Stebalien · 2020-03-19T16:24:36Z

We'd use one of the proposals in the comment you linked: either (a) use a different subdomain <ipns-hash>.ipns-archive.localhost:8080 or (b) <ipns-hash>.ipns.localhost:8080/some/path?backup=<signed-ipns-record>. Both of those solutions work with with this new feature.

This change adds support for DNSLink subdomains on localhost gateway (ipfs/kubo#6096) Example: en.wikipedia-on-ipfs.org.ipfs.localhost:8080 BREAKING CHANGE: `isIPFS.subdomain` now returns true for <domain.tld>.ipns.localhost BREAKING CHANGE: `isIPFS.subdomainPattern` changed License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

* feat: support DNSLink subdomains This change adds support for DNSLink subdomains on localhost gateway (ipfs/kubo#6096) Example: en.wikipedia-on-ipfs.org.ipfs.localhost:8080 BREAKING CHANGE: `isIPFS.subdomain` now returns true for <domain.tld>.ipns.localhost BREAKING CHANGE: `isIPFS.subdomainPattern` changed * test: support peer multiaddr with /p2p/ Context: libp2p/libp2p#79 * fix: explicitly ignore URL param and hash .url and .path now return true when validating: https://ipfs.io/ipfs/<CID>?filename=name.png#foo * refactor: simplify dnslinkSubdomain License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org> * fix: url() check should include subdomain() When .url was created we only had path gateways. When .subdomain was added, we did not update .url to test for subdomain gateways, which in the long run will confuse people and feels like a bug. Let's fix this: .url() will now check for both subdomain and path gateways #32 (comment) BREAKING CHANGE: .url(url) now returns true if .subdomain(url) is true * refactor: merge DNSLink check into ipnsSubdomain() This makes subdomain checks follow what path gateway checks do, removing confusion. In both cases (IPNS and DNSLink) user needs to perform online record check, so this is just a handy way of detecting potential matches. * docs: update examples * refactor: switch to iso-url * refactor: lint-package-json * chore: update deps License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

bmwiedemann · 2020-05-08T07:49:32Z

Seems to break on Linux => #7290

feat: gateway subdomains + http proxy mode This commit was moved from ipfs/kubo@0114869

ghost assigned Stebalien Mar 18, 2019

ghost added the status/in-progress In progress label Mar 18, 2019

Stebalien force-pushed the feat/gateway-subdomains branch 2 times, most recently from bb44c3c to 5abd144 Compare March 25, 2019 12:14

lidel mentioned this pull request Jul 16, 2019

Subdomain Gateway #6498

Closed

lanzafame added the topic/gateway Topic gateway label Jul 17, 2019

This comment has been minimized.

Sign in to view

Stebalien mentioned this pull request Jan 10, 2020

gateway cleanups #6820

Merged

Stebalien force-pushed the feat/gateway-subdomains branch from 5abd144 to 6509e39 Compare January 10, 2020 09:29

lidel force-pushed the feat/gateway-subdomains branch 2 times, most recently from 8af259f to ba96bba Compare January 27, 2020 14:56

Stebalien commented Jan 28, 2020

View reviewed changes

docs/config.md Outdated Show resolved Hide resolved

docs/config.md Outdated Show resolved Hide resolved

docs/config.md Outdated Show resolved Hide resolved

Stebalien commented Jan 31, 2020

View reviewed changes

lidel mentioned this pull request Feb 5, 2020

IPNS: should work with case-insensitive identifiers (Base32) #5287

Closed

lidel force-pushed the feat/gateway-subdomains branch from ccdbf99 to c9dd755 Compare February 11, 2020 22:47

lidel reviewed Feb 27, 2020

View reviewed changes

core/corehttp/gateway_proxy.go Outdated Show resolved Hide resolved

Stebalien commented Feb 28, 2020

View reviewed changes

test/sharness/lib/test-lib.sh Outdated Show resolved Hide resolved

namesys/routing.go Outdated Show resolved Hide resolved

namesys/namesys.go Outdated Show resolved Hide resolved

lidel added a commit that referenced this pull request Mar 3, 2020

test(namesys): proper peerid resolution in /ipns/

a9eb7dc

This switches to peer.Decode as suggested in #6096 (comment) and adds tests for missing PeerID types. License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

Stebalien commented Mar 18, 2020

View reviewed changes

Stebalien and others added 3 commits March 17, 2020 19:34

rename ProxyOption to P2PProxyOption

11c229b

(we're implementing an _actual_ proxy) License: MIT Signed-off-by: Steven Allen <steven@stebalien.com>

feat: IPFS_NS_MAP

848d4c7

Allows static DNSLink mappings with IPFS_NS_MAP. License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

Stebalien force-pushed the feat/gateway-subdomains branch from 8287c2c to b805817 Compare March 18, 2020 02:42

lidel reviewed Mar 18, 2020

View reviewed changes

lidel and others added 3 commits March 18, 2020 08:50

feat(gateway): subdomain and proxy gateway

3ecccd6

License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>

fix(sharness): fix sharness tests to take removed bootstrap peers int…

05fe308

…o account

Stebalien force-pushed the feat/gateway-subdomains branch from 1cf8077 to 05fe308 Compare March 18, 2020 15:51

lidel approved these changes Mar 18, 2020

View reviewed changes

Stebalien merged commit 0114869 into master Mar 18, 2020

Stebalien deleted the feat/gateway-subdomains branch March 18, 2020 16:05

lidel mentioned this pull request Mar 19, 2020

Sandbox resources loaded via a path gateway ipfs/in-web-browsers#157

Open

4 tasks

lidel mentioned this pull request Mar 22, 2020

feat: *.localhost subdomain gateway support with http proxy ipfs/ipfs-companion#853

Merged

20 tasks

lidel mentioned this pull request Apr 3, 2020

feat: allow /ipns/webui.ipfs.io on api port #6530

Closed

lidel mentioned this pull request Apr 16, 2020

Migration to CIDv1 (default base32) ipfs/specs#247

Open

bmwiedemann mentioned this pull request May 8, 2020

gateway subdomains: *.localhost not found #7290

Closed

lidel mentioned this pull request Dec 9, 2022

Hostnames for localhost HTTP gateway ipfs/in-web-browsers#109

Closed

5 tasks

hacdias pushed a commit to ipfs/boxo that referenced this pull request Jan 27, 2023

Merge pull request ipfs/kubo#6096 from ipfs/feat/gateway-subdomains

a31c796

feat: gateway subdomains + http proxy mode This commit was moved from ipfs/kubo@0114869

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: gateway subdomains + http proxy mode #6096

feat: gateway subdomains + http proxy mode #6096

Stebalien commented Mar 18, 2019 •

edited by lidel

Loading

lidel commented Jul 16, 2019 •

edited

Loading

This comment has been minimized.

Stebalien commented Dec 19, 2019

Stebalien commented Dec 19, 2019

Stebalien commented Dec 19, 2019

Stebalien commented Dec 19, 2019

lidel commented Dec 30, 2019 •

edited

Loading

Stebalien commented Jan 3, 2020

alanshaw commented Jan 7, 2020

lidel commented Jan 23, 2020 •

edited

Loading

Stebalien left a comment

lidel commented Jan 30, 2020 •

edited

Loading

Stebalien left a comment

lidel commented Feb 11, 2020 •

edited

Loading

Stebalien Mar 17, 2020

Stebalien Mar 17, 2020

lidel Mar 18, 2020 •

edited

Loading

Stebalien Mar 18, 2020

Stebalien Mar 18, 2020

Stebalien commented Mar 18, 2020

Stebalien commented Mar 18, 2020

lidel Mar 18, 2020 •

edited

Loading

lidel left a comment

Stebalien commented Mar 18, 2020

ilyaigpetrov commented Mar 18, 2020 •

edited

Loading

Stebalien commented Mar 18, 2020

ilyaigpetrov commented Mar 19, 2020 •

edited

Loading

Stebalien commented Mar 19, 2020

bmwiedemann commented May 8, 2020

feat: gateway subdomains + http proxy mode #6096

feat: gateway subdomains + http proxy mode #6096

Conversation

Stebalien commented Mar 18, 2019 • edited by lidel Loading

lidel commented Jul 16, 2019 • edited Loading

Simplify configuration of Gateway features

Gateway Heuristic

Localhost

Public Gateways

If we allow Paths & DNSLink on the same hostname

If DNSLink always takes a priority

Configuration Examples

DNSLink

Path Gateway

Subdomain Gateway

This comment has been minimized.

Stebalien commented Dec 19, 2019

Stebalien commented Dec 19, 2019

Stebalien commented Dec 19, 2019

Stebalien commented Dec 19, 2019

lidel commented Dec 30, 2019 • edited Loading

dweb.link: all-in-one gateway edge case

Different take on the config

Stebalien commented Jan 3, 2020

alanshaw commented Jan 7, 2020

lidel commented Jan 23, 2020 • edited Loading

Some fun screenshots

Stebalien left a comment

Choose a reason for hiding this comment

lidel commented Jan 30, 2020 • edited Loading

Stebalien left a comment

Choose a reason for hiding this comment

lidel commented Feb 11, 2020 • edited Loading

Stebalien Mar 17, 2020

Choose a reason for hiding this comment

Stebalien Mar 17, 2020

Choose a reason for hiding this comment

lidel Mar 18, 2020 • edited Loading

Choose a reason for hiding this comment

Stebalien Mar 18, 2020

Choose a reason for hiding this comment

Stebalien Mar 18, 2020

Choose a reason for hiding this comment

Stebalien commented Mar 18, 2020

Stebalien commented Mar 18, 2020

lidel Mar 18, 2020 • edited Loading

Choose a reason for hiding this comment

lidel left a comment

Choose a reason for hiding this comment

Stebalien commented Mar 18, 2020

ilyaigpetrov commented Mar 18, 2020 • edited Loading

Stebalien commented Mar 18, 2020

ilyaigpetrov commented Mar 19, 2020 • edited Loading

Stebalien commented Mar 19, 2020

bmwiedemann commented May 8, 2020

Stebalien commented Mar 18, 2019 •

edited by lidel

Loading

lidel commented Jul 16, 2019 •

edited

Loading

lidel commented Dec 30, 2019 •

edited

Loading

`dweb.link`: all-in-one gateway edge case

lidel commented Jan 23, 2020 •

edited

Loading

lidel commented Jan 30, 2020 •

edited

Loading

lidel commented Feb 11, 2020 •

edited

Loading

lidel Mar 18, 2020 •

edited

Loading

lidel Mar 18, 2020 •

edited

Loading

ilyaigpetrov commented Mar 18, 2020 •

edited

Loading

ilyaigpetrov commented Mar 19, 2020 •

edited

Loading