multiformats / multiaddr

Composable and future-proof network addresses
https://multiformats.io/multiaddr
MIT License
419 stars 84 forks source link

Define `/http-path` #164

Closed MarcoPolo closed 1 month ago

MarcoPolo commented 10 months ago

Summary

Adds a new multiaddr component for /http-path, and define it.

I think this follows RFC 3986's notion of "Path" (section 3.3). Please correct me if I'm wrong.

I'm using http-path instead of httpath (used by IPNI) previously for two reasons:

  1. I prefer joining two full words.
  2. In case there's any conflicting interpretation, this will be unambiguous as it has a different name.

Before Merge

Winterhuman commented 10 months ago

Out of curiosity, knowing I've probably missed something in the doc which explicitly states this which I didn't understand among the RFC links, are the paths strictly ASCII characters (with punycode needed for UTF-8 conversion), or is encoding the paths as UTF-8 allowed?

MarcoPolo commented 10 months ago

Good question. Section 2 of RFC 3986 covers this. Basically it depends on the context. If the context/protocol is UTF-8, then this is UTF-8. In practice I think the string encoding of this will be UTF-8.

MarcoPolo commented 10 months ago

I think as is, my document is ambiguous. Only the following characters are not percent-encoded: unreserved / pct-encoded / sub-delims / ":" / "@".

I was trying to avoid the ABNF notation from the RFC, but I might have to include it.

achingbrain commented 3 months ago

It's an aesthetic point but /httppath is quite hard to read.

I wonder if it could be /http-path (like /p2p-circuit or /webrtc-direct) or even /http+path, since it doesn't really work without /http and makes that section of the multiaddr more specific?

It also opens the door for other modifiers that might be required to create a valid request touched on in #63, such as /http+host/example.com, /http+header/foo=bar, /http+auth/user:password, /http+cookie/foo=bar etc.

MarcoPolo commented 3 months ago

/http-path works for me. 👍

achingbrain commented 3 months ago

Is a multiaddr with /http-path valid without /http also being present?

If not the spec should say so. If so, it should say how to infer a /http tuple when it's not present.

MarcoPolo commented 3 months ago

Is a multiaddr with /http-path valid without /http also being present?

Yes. There's an example in the spec with just a /p2p component.

/http refers to the other end supporting an HTTP transport. The /http component is defined at https://github.com/libp2p/specs/blob/master/http/transport-component.md.

MarcoPolo commented 1 month ago

I don't expect this component to be present in multiaddrs that a peer shares for connectivity as in Peer Routing Records. Only in cases where you want to reference a specific HTTP resource.

I think DNS records are a good analogy. For example, An A query gives you only ipv4 address to a domain name. It just gives you the thing you need to find the server but doesn't give you anything else. Our routing records should be similar. Just the information to reach a server and its peer id.