feat(rpc): Content-Type headers and IPNS record get/put #11067
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lidel
changed the title
- set application/x-tar when outputting tar (default and --archive) - set application/gzip when compression is enabled (--compress) - update go-ipfs-cmds with Tar encoding type and RFC 6713 compliant MIME types (application/gzip instead of application/x-gzip)
set proper Content-Type headers for RPC endpoints that return binary data: - `dag export`: application/vnd.ipld.car - `block get`: application/vnd.ipld.raw - `diag profile`: application/zip - `get`: application/x-tar or application/gzip (already worked, migrated to new API) uses the new OctetStream encoding type and SetContentType() method from go-ipfs-cmds to specify custom MIME types for binary responses. refs: #2376
Member
|
I feel we can fix multiple bugs here if we make it more generic. I'll prototype in this and cmds PR drafts. |
add dedicated command to retrieve raw signed IPNS records from the
routing system. returns protobuf-encoded IPNS record with Content-Type
`application/vnd.ipfs.ipns-record`.
this provides a more convenient alternative to `ipfs routing get /ipns/<name>`
which returns JSON with base64-encoded data. the raw output can be piped
directly to `ipfs name inspect`:
ipfs name get <name> | ipfs name inspect
spec: https://specs.ipfs.tech/ipns/ipns-record/
also renames test files to http_rpc_* for clarity.
document RPC Content-Type headers for binary responses and new ipfs name get command
replaces Extra-based Content-Type documentation with the new HelpText.HTTP.ResponseContentType field from go-ipfs-cmds. commands updated: - ipfs get: application/x-tar, or application/gzip when compress=true - ipfs dag export: application/vnd.ipld.car - ipfs block get: application/vnd.ipld.raw - ipfs name get: application/vnd.ipfs.ipns-record - ipfs diag profile: application/zip also removes SetResponseContentTypeDesc helper from extra.go as it is no longer needed.
adds `ipfs name put` to complement `ipfs name get`, allowing users to store IPNS records obtained from external sources without needing the private key. useful for backup, restore, and debugging workflows. the command validates records by default (signature, sequence number). use `--force` to bypass validation for testing how routing handles malformed or outdated records. also reorganizes test/cli files: - rename http_rpc_* -> rpc_* to match existing convention - merge name_get_put_test.go into name_test.go - add file header comments documenting test purposes
includes SetContentType() for dynamic Content-Type headers
lidel
changed the title
lidel
approved these changes
Jan 30, 2026
Member
There was a problem hiding this comment.
Went into small rabbit hole of leveraging this to fix multiple user-reported problems and I expanded the scope a bit to make this more useful:
- Content-Type headers for more RPC endpoints - added proper MIME types for
dag export,block get,name get, anddiag profilein addition toipfs get - New
ipfs name get|putcommands - low-level tools for backing up, restoring, and debugging IPNS records without needing the private key.name getalso ensures we have an RPC endpoint that returns the
IANA-registeredapplication/vnd.ipfs.ipns-recordmedia type (the existingrouting getreturns JSON with base64-encoded payload + cant be easily integrated with systems that expectapplication/vnd.ipfs.ipns-recordwithout exposing gateway port too, this solves that devops annoyance) - HTTP RPC API documentation - commands now can declare their Content-Type in
HelpText.HTTP.ResponseContentTypeso http-api-docs that generate https://docs.ipfs.tech/reference/kubo/rpc/ can pick it up (will merge ipfs/ipfs-docs#2248 once RC1 ships)
The underlying go-ipfs-cmds changes (ipfs/go-ipfs-cmds#311) add a generic OctetStream encoding type and SetContentType() function, so commands can set arbitrary Content-Type headers at runtime based on flags like --compress.
Merging as all changes are pretty shallow, low risk, backward-compatible and opt-in (+ we will switch to cmds release anyway once #11148 is merged).
Existing behavior is preserved for commands that don't explicitly set a Content-Type, and we have full test coverage for name get|put.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds correct
Content-Typeto some commands (e.g.ipfs get)ipfs get --compressgives incorrect Header #2376Also
name get|put