fix: remove the requirement on Content-Length on the gateway #64
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is not defined anywhere in the spec https://grep.app/search?q=Content-Length&filter[repo][0]=ipfs/specs and thus shouldn't be tested.
Sending a Content-Length header here is fine if the remote gateway knows the size of the car.
For example I am writing a very fast gateway that use indexed IPIP402 cars with a unixfs offset -> car offset index. This allows to use the
sendfile
syscall to send the car from the drives to the network card without copying it into memory or CPU. An index gives stores offset in the car for offsets in the unixfs file or directories, I need it to implement pathing (I skip parts of the car unrelevent to the request). I can then do a simple substraction and a few additions to get the total size of the car, if this is an info I have to compute anyway I might as well send it to the client. A client could use it to display an accurate download bar or preallocate correctly sized buffers, ...If the car is stored in a caching reverse proxy that already knows it's full size it could want to send the Content-Length header for the same reasons.
The only consideration here is that sending a Content-Length which is missmatched with the underlying size would break things, which is true however this is a violation of the HTTP spec already because HTTP 1.1 pipelining depends on the Content-Length. The http client will catch this.