search

ssbc / ssb-ws

ssb-ws & http server for ssb
MIT License
10 stars 9 forks source link

content-length does not match length of secret blob so loads incorrectly #10

Closed mmckegg closed 6 years ago

mmckegg commented 6 years ago

I am in the process of updating patchwork to use ssb-ws for blobs (instead of the old server ripped out of Patchwork v2 that it has been running for a while) so that I can get secret blobs working.

However, I'm noticing that some images are not loading inline (however do load in a browser when navigated to directly). Upon further inspection, it seems that the headers provided by ssb-ws do not include a content-type and for some reason this sometimes causes the images to not always load load.

It might even be a mac specific thing? It seems that SVGs don't load and neither do the secret blobs, but most others do.

Anyway, this is easily fixed by supplying a content-type header. The old patchwork did this using pull-identify-filetype.

I suggest we try doing the same here! Will give this a go and send a PR if it works.

cc @dominictarr

mmckegg commented 6 years ago

Actually, my new theory is that it is the content-length header causing the problems. I'm guessing that with secret blobs, the hash size will not be matching the content-length. We will probably have to disable this header when secret blobs are being used.

mmckegg commented 6 years ago

Yes it is the content-type. Found a typo in multiblob-http that is causing this to be appended when it shouldn't. See https://github.com/dominictarr/multiblob-http/pull/3

@dominictarr can you take a look and merge?

dominictarr commented 6 years ago

fixed, sorry for leaving the bug in!

dominictarr commented 6 years ago

btw, it is possible for the client to request a content type, and to set a file name (needed for download from browser) https://github.com/dominictarr/multiblob-http#caching--headers