search

textileio / go-textile

[DEPRECATED] Textile is a set of tools and infrastructure for building composable apps and services on the IPFS network
https://textile.io
MIT License
357 stars 43 forks source link

Gateway is sending an empty Content-Type header back to a browser as opposed to a one the file should be #840

Closed mysliwiec-tech closed 5 years ago

mysliwiec-tech commented 5 years ago

Describe the bug When my web app is downloading an mp3 file from a Textile Gateway it cannot determine it's length (in seconds) because the Content-Type is empty as opposed to audio/mpeg. All it needs to be working is the correct Content-Type header.

To Reproduce

  1. Add an *.mp3 file to an encrypted thread.
  2. Open a browser's Developer Tools -> Network tab.
  3. Access the file through a gateway in a way as it to be downloaded.
  4. In the Network tab find the file that was downloaded and verify the Content-Type

Expected behavior I would expect that file mime/content-type will be set according to what is in the meta of the encrypted file because it is recognized properly when it's being added to a thread (correct /meta): image

Screenshots When file is being served from a gateway, it is being served as Content-Type: (just an "empty" Content-Type) image

Tray app (please complete the following information):

Additional context The sampotts/plyr library and even the standard HTML5 audio file player (build into a browser) cannot determine the *.mp3 duration and other properties of a file. The HTML that is running the audio player. Because a file is served with a wrong Content-Type user cannot seek through a file. The html file that is serving a player: index.html.txt

sanderpick commented 5 years ago

Hey @mysliwiec-tech - If the content is encrypted, it doesn't make sense to me to guess the underlying content type. If you add the key, the browser can correctly sniff the type:

https://eu-west.cafe.textile.io/ipfs/QmZxL21Veakq3k9dMtiYbp3DoT69mWTEKQCJFdkFomJV6N?key=2PVQp2JiDjcGs9o6wAQsM8HQq3SwWRiiG1FY5HWiE35zV7xPyNaDZfW26J6oE

Additionally, you can add the extension and the gateway will ignore it... this may help an older browser:

https://eu-west.cafe.textile.io/ipfs/QmZxL21Veakq3k9dMtiYbp3DoT69mWTEKQCJFdkFomJV6N.mp3?key=2PVQp2JiDjcGs9o6wAQsM8HQq3SwWRiiG1FY5HWiE35zV7xPyNaDZfW26J6oE

mysliwiec-tech commented 5 years ago

Seems like my previous investigation was wrong - previously I made wrong assumption. Seeking is enabled by sending 206 HTTP code and Content-Range header response. Do you think it will be enabled any time in the future for a gateway? Source eg.: https://github.com/jalik/jalik-ufs/issues/92 https://sitefinitydevelopment.com/blog/here-is-how-to-make-chrome-seek-through-your-audio-files-in-sitefinity.html

mysliwiec-tech commented 5 years ago

Closing as it was identified as the problem with a gateway not supporting Range request headers. Raised a Feature request #843