Support Query Parameters?

[jphastings]

Would IPFS be interested in supporting _redirects files with query parameters, similar to Netlify)? (Re: ipfs/kubo#8890). If this seems valuable, I'd put a PR together (here and in ipfs/kubo).

I would find it valuable to be able to write a redirects file similar to the one below, to be able to provide responses to 'dynamic-looking' web-requests (from clients that expect to use specific, query parameter-based, GET APIs) via IPFS:

/things type=:type /things/:type.html 200
/things /things.html 200

(This is identical to the format Netlify uses — only required parameters must be specified.)

GET /things?type=photos → Served from /things/photos.html
GET /things → Served from /things.html

[jphastings]

I ended up implementing it anyway 😅

Let me know your thoughts!

[aschmahmann]

This is effectively a spec change so should be resolved via a proposed IPIP change (https://github.com/ipfs/specs/tree/main#interplanetary-improvement-process-ipip) in https://github.com/ipfs/specs.

The proposal template highlights some questions around benefits, alternatives, tradeoffs, etc. that would likely be helpful to reviewers.

From what I can tell it seems like this could potentially introduce problems for users as new proposals come along that natively add query parameters to the URI such as IPIP-402. It would effectively add a sense of non-reproducibility to ipfs:// URIs (i.e. the actual target resource changing not just something like how a directory is rendered in HTML) which seems like something to be avoided if possible.

[jphastings]

Thank you so much @aschmahmann! This is super helpful feedback; I'll review IPIP-402 (and any others referencing the HTTP gateway) and build an IPIP of my own.

[lidel]

Ok, so IPIP never happened :) and it seems that there was no interest in this for the past two years.

From what I see the thing proposed here:

from [param1..] to [param2..] code

remains to be a Netlify-specific (and overly complicated) notation (not good).

As of 2025 Q1, Cloudflare does not support this advanced notation,
but it does support turning path placeholders into query params:

• https://developers.cloudflare.com/pages/configuration/redirects/#per-line

  /blog/* https://blog.my.domain/:splat
  /products/:code/:name /products?code=:code&name=:name
  

What we proposed in ipfs/specs#498 and ipfs/boxo#886 is to NOT implement Netlify notation, but clarify spec that implementations SHOULD preserve any user-provided query parameters.

This keeps file format

from to code

but allows including query params in from, to, and :splat.

Feels like a practical compromise.

I'm closing this and related PRs, but if @jphastings or someone else wants to argue for adoption of Netlify syntax (e.g. if Cloudflare or any other popular hosting adopts it), that would be a potentially breaking change for file-format, and requires IPIP to be filled in https://github.com/ipfs/specs/

[jphastings]

Thanks @lidel — apologies for not creating the IPIP! This fully dropped off my radar.

What you're moving forwards with doesn't allow for mapping HTTP resources with query parameters to IPFS resources, but adapting to that need is, as you say, not being called for from others and adds significant complexity.

I appreciate the compromise, thank you!