-
Notifications
You must be signed in to change notification settings - Fork 116
bitswap/httpnet: request with CDN-Loop (RFC 8586) #862
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
Comments
@lidel we could simply not support redirects... Our urls come from content provider records, which, iirc, have expirations and need to be renewed regularly. If an endpoint changes, the action to take is to update the provider record, rather than setting a redirect. It's also not even about loops, its also about redirect hops (1 hop means opening a new connection somewhere else which is already expensive by itself in our context). |
@hsanjuan good point. not following redirects sounds ok to me. interpreting 3XX as 404 will force people to update announcements rather than keeping dead domains alive and then breaking months/years later. still, the utility of perhaps for now, disable following redirects, and keep this issue about |
Avoid following redirects. We treat them as an incorrect provider record. We don't want to be coerced into opening new connections to new hosts and we prefer provider records to be up to date rather than them relying in redirects being followed. There are also problems with potential loops etc. #862
* bitswap/httpnet: do not follow redirects Avoid following redirects. We treat them as an incorrect provider record. We don't want to be coerced into opening new connections to new hosts and we prefer provider records to be up to date rather than them relying in redirects being followed. There are also problems with potential loops etc. #862 * bitswap/httpnet: close response bodies "The default HTTP client's Transport may not reuse HTTP/1.x "keep-alive" TCP connections if the Body is not read to completion and closed."
We need to find a solution to situation where defunct gateways start returning redirects back to
ipfs.io
anddweb.link
, effectively acting as amplification vector.There is some prior art solution in form of
CDN-Loop
header which helps in avoiding unintended HTTP loops like that:Ref.
I think in case of Rainbow, we could leverage SEED and have all nodes set
CDN-Loop
to the same deterministic hash value, and refuse to process requests with matching one. This way HTTP traffic looped/proxied back to our infra is ignored.cc @hsanjuan for feedback, maybe there a better way?
The text was updated successfully, but these errors were encountered: