Skip to content

gateway: clarify 3XX on trustless gw #494

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

lidel
Copy link
Member

@lidel lidel commented Mar 4, 2025

Writing down clarification proposed by @hsanjuan idea from ipfs/boxo#862 (comment)

This PR clarifies that trustless gateways and clients SHOULD avoid returning and processing HTTP 3XX redirects. Gateway URL changes should be performed by updating entry in routing systems instead.

Rationale:

  • 3XX redirects create unnecessary overhead for trustless clients
  • opt-out from following redirects is relatively easy to implement:

cc @hsanjuan (boxo/rainbow) and @SgtPooki @2color (helia/verified-fetch/inbrowser.link) for feedback.

3XX create unnecessary overhead and it is desirable
for spec to nudge implementers towards best practices
that remove redirect overhead from server and client
and shift solution to updating entry in routing system
### `3XX` Redirects

Non-recursive trustless gateway SHOULD NOT return HTTP redirects.
Change of URL should occur by announcing it to the routing system.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change of URL should occur by announcing it to the routing system.

i'm slightly confused by this line.. which routing system?

do you mean to imply that clients receiving a 3xx redirect from a spec-compliant trustless gateway should detect the 3xx and handle it appropriately?

maybe it's just too late for me.

Comment on lines +317 to +321
Error indicating that the request was syntactically valid, but traversal
of the requested content path failed due to an invalid or missing DAG node.

This error SHOULD occur when either the root CID is not provided by the gateway
or a specified sub-path does not exist within the DAG referenced by the root CID.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are touching these in #491 , should we merge that first?

Comment on lines +238 to +250
## Response Status Codes

### `200` OK

The request succeeded.

If the HTTP method was `GET`, then data is transmitted in the message body.

### `404` Not Found

Error to indicate that requested resource is not provided by the gateway.

### `3XX` Redirects
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same, unsure how this plays with #491 and path-gateway status codes. Should we edit there instead?

Begs the question, does it make sense that a recursive trustless gateway redirects and the non-recursive doesn't?

Non-recursive trustless gateway SHOULD NOT return HTTP redirects.
Change of URL should occur by announcing it to the routing system.

Clients SHOULD ignore redirects and interpret them the same way as `404`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does the client know that it is talking to a non-recursive gateway though? Ideally the same client should work for all the gateways pretty much the same so the requirement is a bit weird (in some cases redirects should be followed and in others not).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants