Define /http-path

[MarcoPolo]

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

• Allow at least 24 hours for community input
• If this is a new protocol, has the change been applied to https://github.com/multiformats/multicodec as well? If so, please link the multicodec PR.

[Winterhuman]

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]

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]

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]

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]

/http-path works for me. 👍

[achingbrain]

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]

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.

[achingbrain]

LGTM.

One thing that occurs is that implementations tend to omit the Peer ID from Multiaddrs that are part of PeerInfo objects.

This new segment must be after the Peer ID so these implementations would have to start including the Peer ID which would increase the size of signed peer records, the amount of data transferred during network queries, etc.

[MarcoPolo]

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.