* fix(core/gateway): option to limit directory size listing
* feat(gw): HTMLDirListingLimit
This is alternative take on the way we limit the HTML listing output.
Instead of a hard cut-off, we list up to HTMLDirListingLimit.
When a directory has more items than HTMLDirListingLimit we show
additional header and footer informing user that only $HTMLDirListingLimit
items are listed. This is a better UX.
* fix: 0 disables Gateway.HTMLDirListingLimit
* refactor: Gateway.FastDirIndexThreshold
see explainer in docs/config.md
* refactor: prealoc slices
* docs: Gateway.FastDirIndexThreshold
* refactor: core/corehttp/gateway_handler.go
https://github.com/ipfs/go-ipfs/pull/8853#discussion_r851437088
* docs: apply suggestions from code review
Co-authored-by: Alan Shaw <alan.shaw@protocol.ai>
Co-authored-by: Marcin Rataj <lidel@lidel.org>
Co-authored-by: Alan Shaw <alan.shaw@protocol.ai>
The gateway accepts an X-Ipfs-Path-Prefix header,
and assumes that it is mounted in a reverse proxy
like nginx, at this path. Links in directory listings,
as well as trailing-slash redirects need to be rewritten
with that prefix in mind.
We don't want a potential attacker to be able to
pass in arbitrary path prefixes, which would end up
in redirects and directory listings, which is why
every prefix has to be explicitly allowed in the config.
Previously, we'd accept *any* X-Ipfs-Path-Prefix header.
Example:
We mount blog.ipfs.io (a dnslink page) at ipfs.io/blog.
nginx_ipfs.conf:
location /blog/ {
rewrite "^/blog(/.*)$" $1 break;
proxy_set_header Host blog.ipfs.io;
proxy_set_header X-Ipfs-Gateway-Prefix /blog;
proxy_pass http://127.0.0.1:8080;
}
.ipfs/config:
"Gateway": {
"PathPrefixes": ["/blog"],
// ...
},
dnslink:
> dig TXT _dnslink.blog.ipfs.io
dnslink=/ipfs/QmWcBjXPAEdhXDATV4ghUpkAonNBbiyFx1VmmHcQe9HEGd
License: MIT
Signed-off-by: Lars Gierth <larsg@systemli.org>
We now consider debugerrors harmful: we've run into cases where
debugerror.Wrap() hid valuable error information (err == io.EOF?).
I've removed them from the main code, but left them in some tests.
Go errors are lacking, but unfortunately, this isn't the solution.
It is possible that debugerros.New or debugerrors.Errorf should
remain still (i.e. only remove debugerrors.Wrap) but we don't use
these errors often enough to keep.
