This content has been added to IPFS in block mode with the js-ipfs-http-client through a Buffer no filename is involved.
2 - While checking the Response Header I received the proper content Header however non compressed.
content-type: text/html; charset=utf-8
3 - I did the same test here:
gateway.ipfs.io
and received an appropriate Response Header with compressed content:
content-encoding: gzip
content-type: text/html
4 - As a side note ipfs.infura.me sent me a content-length while gateway.ipfs.io didn't
5 - There is an general improvement who could be done here at the go-ipfs gateway level. In the current version go-ipfs v0.5.0. If you upload to ipfs a compressed html content, the gateway do not provide the appropriate Response Header. I started a feature request conversation thread with the go-ipfs team here:
Dear Friends,
1 - I noticed that retrieving an HTML content from IPFS using your gateway I received non compress content. Here is a link from a content I uploaded:
ipfs.infura.io Gateway
This content has been added to IPFS in block mode with the js-ipfs-http-client through a Buffer no filename is involved.
2 - While checking the Response Header I received the proper content Header however non compressed.
content-type: text/html; charset=utf-83 - I did the same test here: gateway.ipfs.io and received an appropriate Response Header with compressed content:
4 - As a side note ipfs.infura.me sent me a content-length while gateway.ipfs.io didn't
5 - There is an general improvement who could be done here at the go-ipfs gateway level. In the current version go-ipfs v0.5.0. If you upload to ipfs a compressed html content, the gateway do not provide the appropriate Response Header. I started a feature request conversation thread with the go-ipfs team here:
https://github.com/ipfs/go-ipfs/issues/7268
As a public api and gateway provider your perspective and participation could help a wider improvement.
Thanks