Oddbean

I didn't know IOS required range requests for videos to work but i guess it makes sense right now the blossom spec does not mention anything about content-length or accept-ranges but it might be good to add it, thoughts?

fwiw im not sure if it is the issue, its just the biggest thing i saw that was different between the headers of the server responses. Would be good to know which header specifically is the issue, assuming both servers are returning the same data and there isn’t some other subtle issue.

i wouldn't be so bold, since i din't mess directly with the headers. I just used a different API http.ServeContent, that handles the headers for me. It might any other header handled by this API that we were not aware of. We should conduct tests manually setting headers to check which one is the one required by iOS. or simply leave it be, and document that videos might not work in iOS without extra headers, and let the devs fend for themselves.

BotGPT: “When dealing with video playback on iOS devices, especially when using third-party video storage servers, it's important to ensure that the server's response headers are properly configured to support smooth streaming and playback. Here are some key HTTP headers and their ranges that you should consider: 1. **Content-Type**: This header indicates the media type of the resource. For video files, common types include: - `video/mp4` for MP4 files - `video/quicktime` for MOV files - `video/x-ms-wmv` for WMV files - `video/webm` for WebM files 2. **Accept-Ranges**: This header should be set to `bytes` to indicate that the server supports range requests. This is crucial for seeking within the video. - Example: `Accept-Ranges: bytes` 3. **Content-Length**: This header specifies the total size of the video file in bytes. It is important for the client to know the size of the file for buffering and playback. - Example: `Content-Length: 12345678` 4. **Content-Range**: This header is used in response to a range request. It indicates the range of bytes being sent in the response and the total size of the file. - Example: `Content-Range: bytes 0-999/12345678` 5. **Cache-Control**: This header can be used to control caching behavior. For video content, you might want to set it to prevent caching or allow it based on your needs. - Example: `Cache-Control: no-cache` or `Cache-Control: public, max-age=3600` 6. **Expires**: This header can be used to specify when the content should be considered stale. It can be set to a future date to allow caching. - Example: `Expires: Wed, 21 Oct 2025 07:28:00 GMT` 7. **Cross-Origin Resource Sharing (CORS)**: If your video is hosted on a different domain, you may need to set CORS headers to allow access from your iOS app. - Example: `Access-Control-Allow-Origin: *` 8. **Content-Disposition**: This header can be used to suggest how the content should be handled (inline or as an attachment). - Example: `Content-Disposition: inline; filename="video.mp4"` ### Example of a Response Header for Video Playback Here’s an example of what the response headers might look like for a video file: ``` HTTP/1.1 206 Partial Content Content-Type: video/mp4 Accept-Ranges: bytes Content-Range: bytes 0-999/12345678 Content-Length: 1000 Cache-Control: no-cache Expires: Wed, 21 Oct 2025 07:28:00 GMT Access-Control-Allow-Origin: * ``` ### Summary To ensure optimal video playback on iOS devices from a third-party video storage server, make sure to implement the above headers correctly. This will help facilitate smooth streaming, seeking, and overall better user experience.”

Partial content goes beyond headers. It requires additional logic to handle the correct ranges, HTTP status codes, and more. The `http.ServeContent` function took care of all this for you. No worries about being "bold" here. I’d much rather have range requests explicitly specified in the Blossom specs (it’s a crucial feature for a media server anyway) than deal with more half-baked, hardcoded headers scattered everywhere. We already have too many incorrect or overly simplified assumptions about how HTTP works baked into most Nostr libraries, clients, and relays. Having something in the standarda is actually the right approach if we want Blossom to succeed.

These are both pretty important for mobile, since sometimes we refuse to download things that are too big in low data mode, and ranges are nice for incremental downloads. Could mention it as a “SHOULD”