Excellent -- that's not ideal, but it's better than being shut out completely until this is resolved. Do you have any theories as to why Safari is able to pull the files using that method, but not when tapping the link normally? Does it all tie into the cookie/session issue you outlined above, in your opinion? Once again, really appreciate your troubleshooting and looking into this @cousinslick.

With the download option in iOS, it seems to be bypassing the internal player and its cookieless range requests:

GET /attachment.php?aid=1281340 HTTP/1.1
Host: preggophilia.com
Accept: */*
Cookie: loginattempts=1; mybb[lastactive]=1710536409; mybbuser=406_~~ynLT; sid=246~~d80; mybb[lastvisit]=1710536388
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 17_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Mobile/15E148 Safari/604.1
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

The attachment script knows how to handle this request, so the file downloads. The browser/video tag requests are going through the internal player which is making different kinds of requests to get the video file. 

I’d probably start with the range request handling in attachment.php since even though its annoying, it’s semantically logical. Even if it’s just returning 416 and a content-range header when it receives a request for a range with an end byte (i.e., no range header or range: byte=0- returns 200 and the content as it does today but range: byte=x-y returns 416).

The cookie bit is going to come down to how you want to deal with protecting attachments. Query parameters seem to pass through; I’d probably cook up a simplistic time-based access token scheme and tack it onto the query string, enhance the attachment script to handle it. (But this is also the kind of reason why I got out of the web dev business.)

But ultimately this feels like a solved problem—others have figured out how to make it work, it’s just a matter of finding the details and implementing it here.

(March 15, 2024, 6:03 pm)cousinslick With the download option in iOS, it seems to be bypassing the internal player and its cookieless range requests:

GET /attachment.php?aid=1281340 HTTP/1.1
Host: preggophilia.com
Accept: */*
Cookie: loginattempts=1; mybb[lastactive]=1710536409; mybbuser=406_~~ynLT; sid=246~~d80; mybb[lastvisit]=1710536388
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 17_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Mobile/15E148 Safari/604.1
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

The attachment script knows how to handle this request, so the file downloads. The browser/video tag requests are going through the internal player which is making different kinds of requests to get the video file. 

I’d probably start with the range request handling in attachment.php since even though its annoying, it’s semantically logical. Even if it’s just returning 416 and a content-range header when it receives a request for a range with an end byte (i.e., no range header or range: byte=0- returns 200 and the content as it does today but range: byte=x-y returns 416).

The cookie bit is going to come down to how you want to deal with protecting attachments. Query parameters seem to pass through; I’d probably cook up a simplistic time-based access token scheme and tack it onto the query string, enhance the attachment script to handle it. (But this is also the kind of reason why I got out of the web dev business.)

But ultimately this feels like a solved problem—others have figured out how to make it work, it’s just a matter of finding the details and implementing it here.

Much appreciated @cousinslick -- this is something that we'll need to fix.

@Admin @cousinslick Can confirm does not work in other browsers on iOS. I tested the downloading too and that works with the links.

Honestly, it wouldn't hurt to do it like that. Another forum I follow only posts the links to each attachment with a thumbnail. You have to open in a new tab to view the video and this occurs on both mobile and desktop.

(March 15, 2024, 8:03 pm)wrathoflego @Admin @cousinslick Can confirm does not work in other browsers on iOS. I tested the downloading too and that works with the links.

Honestly, it wouldn't hurt to do it like that. Another forum I follow only posts the links to each attachment with a thumbnail. You have to open in a new tab to view the video and this occurs on both mobile and desktop.

Yes, sadly videos don't appear to work on iOS at all (Chrome or Safari). They work on MacOS within non-Safari browsers. The only workaround within iOS is to hold down (tap and hold) and then download the actual file, if it's an MP4. WebMs don't appear to work at all.

When it does work, the video loads metadata and a few seconds, which effectively serves as a preview. The script lacks the ability to process videos and generate an actual image-based preview.