Store HTTP response headers and body separately

[ivilata]

This is a followup of #1, which covers two different subjects. This particular issue is about splitting the to-be-cached HTTP response into two pieces (response headers and response body) and storing them separately.

As indicated in #1:

This may help reuse the distributed cache when the same document data is uploaded or requested on different occasions (e.g. with changing caching headers) or via completely different applications using the same storage backend.

From @inetic:

I kind of see the point in [splitting the header and body into different pieces], e.g. some app could store a raw cat.jpg picture into the cache and fetch it without the header. On the other hand such app could easily download it with the header in a same manner as it would if it was downloading it using HTTP. Another argument against this could be that it (likely) takes longer to search into the DHT for two items than for just one.

From @ivilata:

[…] by uploading content as is we don't force other apps to use the HTTP-like (or any other) encoding. As for doubling the number of requests to the DHT, I'd expect for its cost to be overtaken by IPFS DHT queries to fetch the body. Also, if we have an actual browser with its own cache using the client, it may try actual HTTP HEAD requests beforehand which may result in less and smaller transfers (just the head).

Regarding [splitting the header and body into different pieces], by uploading content as is we don't force other apps to use the HTTP-like (or any other) encoding. As for doubling the number of requests to the DHT, I'd expect for its cost to be overtaken by IPFS DHT queries to fetch the body. Also, if we have an actual browser with its own cache using the client, it may try actual HTTP HEAD requests beforehand which may result in less and smaller transfers (just the head). […] Also, please note that when several requests map to the same content (e.g. because the server ignores or lacks most accepted languages), several clients which used different canonical requests may still provide the content to others, but only as long as head and body are stored separatedly […].