Is there some "easy" way of implementing the HEAD endpoint myself? I was thinking to create custom "proxy" endpoint which would accept both byte-range headers and the HEAD request -> this endpoint would take the byte-range headers and forward them to the S3 file url and then return the ranged response.

Technically, it should be enough to add the same GET file download route but with a HEAD.
This should work because internally the actual file serving is done by the standard http.ServeContent, which'll check for the request method and skip the body write. But it needs to be tested.

Btw. why the reverse proxy is an issue? Do you think it would be an issue even with the implementation i mentioned?

It is not an issue, it could actually be a valid workaround. You can implement the proxy cache workaround if you don't want to wait for the next release (there are no ETAs yet) mentioned in #1125 (comment).

I think I can wait for the release, I see you release new versions quite often

@ganigeorgiev this is exactly what I had in mind: https://medium.com/@radhian.amri/video-streaming-using-http-206-partial-content-in-go-4e89d96abdd0
Echo is obviously making it easy

@apikee
The range requests handling comes from the standard library - http.ServeContent.
It should work with any io.ReadSeaker compatible struct (including the blob.Reader from the google/go-cloud/blob that we currently use).

Since the lack of HEAD request could be a blocker for users who rely on previewing media files in Safari, I've pushed a fix as minor v0.13.1 release.

Please also note that for better performance when serving large files with enabled S3 storage, you may want to use directly the S3 CDN url (if available) instead of the /api/files/... route (there will be eventually option for this in the Admin UI as part of #28 and its PR #986). The raw S3 object name follows the format: /collectionId/recordId/filename.

wow, thank you for the quick action!