Document IPNI HTTP provider specification

[masih]

Rendered

Note: I have opted for least disruptive spec relative to the current implementation. If you folks think this doesn't matter as much there are things that I'd like to change.

Fixes #16

[willscott]

this looks like a good extraction of what we expect from the provider

[gammazero]

This is excellent

[rvagg]

It might be nice to leave open (and document here) the ability of announcement Addrs to include optional httpath specifier, and be clear how this interacts with the new path prefixes defined here. If I provide an httpath in a multiaddr, does it override /ipni/v1/ad/, or does it prepend to this?
My own limited use of this has involved wanting to change the default provider server that responds to /head and /{cid} to one that responds on /_ipni/head and /_ipni/{cid} because I want to reuse an existing server that has other things going on at the root. So I like that this is now namespaced; I also like optionality, but it's not critical now that this is so specific. i.e. custom httpath could be ruled out in this spec and I wouldn't be too upset, but I'd like the clarity.

[masih]

@rvagg thank you for pointing httpath out. I have added a Namespacing section to spell out how I think the extra paths are to be handled here.

Can I ask you to give it a read and let me know what you think please?

Also captured ipni/go-libipni#42

[rvagg]

great! I've followed up in ipni/go-libipni#42

[masih]

Cc @lidel @aschmahmann

[BigLep]

Doh - my original comment was in the wrong issue - my bad!

[BigLep]

Don't block on anything from me. Just left comments while reading through after it came up during the Content Routing WG on 2023-05-30. Thanks.

[lidel]

@masih added my usual comments about including explicit headers for HTTP Caching + some questions/concerns around /httpath