You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
How to follow recommendations for including HTTP semantics using go-multiaddr #254
However, my read is that this implementation would, by default, error trying to encode/decode such multiaddrs as the protocols would not be part of the protocol table.
Is the recommendation to call AddProtocols on every machine your application runs on an add your additional protocol?
Also is this still the recommendation given http-path was later added as a default included protocol?
Do you need anything else besides the path? I don't think it makes sense to encode the method type or parameters since this is just talking about a specific resources. If you need to encode those I think the linked recommendation is still good. You would call AddProtocols as part of your application, and that runs everywhere your application does.
Activity
MarcoPolo commentedon Oct 1, 2024
Thanks for linking that. I should update that documentation to remove the references to http-path since we do, in fact, have that.
Here's some context on why I changed my mind around
http-path: ipni/go-libipni#42 (comment).Do you need anything else besides the path? I don't think it makes sense to encode the method type or parameters since this is just talking about a specific resources. If you need to encode those I think the linked recommendation is still good. You would call AddProtocols as part of your application, and that runs everywhere your application does.
hannahhoward commentedon Oct 3, 2024
this describes what we're trying to do: ipni/go-libipni#230
TLDR: http-path will work, but it's probably somewhat abusing the concept for an unintended purpose.