<!– Output From
ipfs version --all –>
go-ipfs version: 0.4.3- Repo version: 4 System version: amd64/linux Golang version: go1.7
<!– Bug, Feature, Enhancement, Etc –>
<!– One of following: Critical - System crash, application panic. High - The main functionality of the application does not work, API breakage, repo format breakage, etc. Medium - A non-essential functionality does not work, performance issues, etc. Low - An optional functionality does not work. Very Low - Translation or documentation mistake. Something that really does not matter much but should be noticed for a future release. –>
Severity: Medium (performance issue)
/ipfs/ request have maximal caching implemented, which is great for performance as it allows offloading load to caches (reverse proxies, Cloudflare, browser, etc). The
/ipns/ are mutable, so the same treatment would not work. Currently, they don’t provide any form of caching, making every request go all the way back to the (comparatively slow) origin node.
There is currently a very low severity bug in the handling of the
If-None-Match header for
/ipns/ requests. It is incorrectly handled like the
/ipfs/ requests, and returns
304 Not Modified if set to the ipns base name, even though the content may have changed. This is very low severity since
/ipns/ never sets an
ETag header to begin with.
I propose to implement the following:
/ipns/requests always set the
ETagto the current
If the request contains a
If-None-Matchheader, check the ETag and reply with
304 Not Modifiedif appropriate.
Add a configuration option
If the boolean is set, reply to
/ipns/requests with a 307 redirect to the current
/ipfs/path and include a header for 5 minute caching. (ipns updates, AFAIK, have no global consistency guarantees, so this should not hurt. Even a slight caching header can be the difference between 10k requests per second and 1 request per minute.)
If the boolean is not set, reply as before, but also include the ETag header described above.
Relevant prior discussions:
Redirection has been mentioned earlier in issue 132:
- should use relative 302 (or 303/307) redirects for resolving /ipns -> /ipfs
Issue 132 is closed, but this particular feature is currently not implemented. In issue 1234 it was suggested again, but at least one user had a problem with it in the context of dns links (something I don’t understand).
- Does the config option make sense or is it too much and can I always enable redirects?
- Should the redirect cache duration be configurable? What is a good default?
- Is there a reason this is not implemented yet that I should know of?
- How does this affect dns link?