Ok I'll add
https://pkg.go.dev/net/http#ServeContent - this is what you are looking for (it will handle partial byte ranges and all mentioned headers).
but AFAIK, this needs to be done on khatru, because it does not expose the required objects. that's why i involved @fiatjaf in the thread.
Try to replace `io.Copy` with `http.ServeContent` and see what happens (you can fork Khatru and use go to replace khatru dependency in Haven, this is how I tested all of the CORS stuff before)
this worked wonders! I'll keep testing it and submit a pull request by tomorrow. the changes were a little more complex than just adding a call to ServeContent (they always are) but i think i managed to get everything right. see here: https://github.com/fiatjaf/khatru/compare/master...girino:khatru:master (there is still some debug "prints" in there, i'll remove them before the pull request)
Looking good! If you’re open to a small suggestion, and if fiatjaf doesn’t mind introducing some early-stage backwards-incompatible changes to khatru's Blossom’s API, I think you could simplify things by changing the return type here https://github.com/fiatjaf/khatru/blob/76ecf4f7914a93b7ec4f0cc0c823304a7402adab/blossom/server.go#L18 to `io.ReadSeeker`. This would allow you to eliminate the `io.Copy` fallback code and the `Content-Type` handling, as `http.ServeContent` also takes care of that for you. It even handles ETags and cache-related headers, so I’d expect your patch to significantly improve things for all clients—not just iOS. Well done!
i thought about that, but was afraid it would break other people code... that's up to @fiatjaf... what do you think?
If you break other people’s code with backwards incompatible things, kindly start a tracker here: https://github.com/nostrability/nostrability
If it helps, it use to return `[]byte` and khatru Blossom's API own example was broken until a couple of weeks ago. It's ultimately Fiatjaf's decision of course, but, from my perspective, feel free go for it.