Remove unsupported URLs from :::tip section.

[da2x]

ipfs-docs/docs/how-to/address-ipfs-on-web.md

Lines 47 to 57 in 5523597

	For example, a website can load static assets from content-addressed paths:
	```
	<link rel="stylesheet" href="https://example.com/ipfs/QmNrgEMcUygbKzZeZgYFosdd27VE9KnWbyUD73bKZJ3bGi?filename=style.css">
	```
	```
	<link rel="stylesheet" href="/ipfs/QmNrgEMcUygbKzZeZgYFosdd27VE9KnWbyUD73bKZJ3bGi?filename=style.css">
	```
	Browsers that support IPFS will recognize the `/ipfs/<CID>` content path and load the related asset over IPFS instead of HTTP.

Brave doesn’t support this, and it’s the only web browser with built-in support for IPFS. Brave only supports the ipfs:// and ipns:// schemes, and the x-ipfs-path HTTP response headers. The IPFS Companion supports this, but it should probably be removed. This “tip“ section should be removed from the documentation.

For instance, this root-path prefix isn’t mention again in the dweb addressing section.

ipfs-docs/docs/how-to/address-ipfs-on-web.md

Lines 21 to 29 in 5523597

	## Dweb addressing in brief
	- In IPFS, addresses (for content) are path-like; they are components separated by slashes.
	- The first component is the protocol, which tells you how to interpret everything after it.
	- Content referenced by a hash might have named links. (For example, a Git commit has a link named `parent`, which is really just a pointer to the hash of another Git commit.) Everything after the CID in an IPFS address are those named links.
	- Since these addresses aren’t URLs, using them in a web browser requires reformatting them slightly:
	- Through an HTTP gateway, as `http://<gateway host>/<IPFS address>`
	- Through the gateway subdomain (more secure, harder to set up): `http://<cid>.ipfs.<gateway host>/<path>`, so the protocol and CID are subdomains.
	- Through custom URL protocols like `ipfs://<CID>/<path>`, `ipns://<peer ID>/<path>`, and `dweb://<IPFS address>`

[johnnymatthews]

This issue is fair. I believe at some point the above example did work, but looks like it doesn't anymore. @da2x your point about Brave not supporting this being a big thing is valid. The fix is pretty trivial here, just rip out that example.

[lidel]

Brave doesn’t support this, [..]

Brave is not the reference user agent, it is a user agent that makes their own decisions based on external factors :)

• They do have experimental opt-in redirect support, but it needs more work, including fixing bugs like Change DNSLink url resolution to <gateway>/ipns/<dnslink-domain> brave/brave-browser#20567
  • IPFS Stewards&Ecosystem are working with Brave team to get their native support for redirects and DNSLink detection closer to what IPFS Companion does (including DNS lookup instead of reliance on HTTP header etc), but hey have own policy around default behaviors on https://
  • iirc native redirects in Brave have additional constraints because of Brave Shield / limiting impact on https:// websites: requests for subresources on https:// are not redirected, this will happen only if the root document was loaded from ipfs:// or ipns:// (unsure if this shipped, but remember this was a recent fix to fix broken subresources where redirect clashed with rules enforced by Brave Shields)

this root-path prefix isn’t mention again in the dweb addressing section.

It is, but maybe not clear enough?
We could make it more explicit here:

-Through an HTTP gateway, as `http://<gateway host>/<IPFS address>` 
+Through an HTTP gateway, as `https://<gateway host>/ipfs/<cid>` 

@johnnymatthews Commented on (#1003) and suggested tweaking language to be about user agents and focusing on what Companion does (as the reference user agent that maximizes opportunity for protocol upgrade), and not a specific browser.