How to handle `upgrade-insecure-requests` ?

#125 · open · 2 comments

View on GitHub ↗

F1LT3R

How should `upgrade-insecure-requests: 1` be handled when encountered in the response header? ```js { host: 'localhost:8443', 'user-agent': 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0', accept: 'text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8', 'accept-language': 'en-US,en;q=0.5', 'accept-encoding': 'gzip, deflate, br', authorization: 'Digest username="admin", realm="Users", nonce="54d33865...", uri="/Big_Buck_Bunny_360_10s_5MB.mp4", algorithm=MD5, response="1ed75a58...", qop=auth, nc=00000007, cnonce="5e6299d2..."', connection: 'keep-alive', 'upgrade-insecure-requests': '1', // <-------------- HERE 'sec-fetch-dest': 'document', 'sec-fetch-mode': 'navigate', 'sec-fetch-site': 'none', 'sec-fetch-user': '?1' } ``` When I receive this header, there is no `sendStatus()` function on the http `response` argument.

Comments

F1LT3R

I do not have an issue accessing the mp4 video from an html page (playing it inline), but a direct visit to the mp4 link does not allow the video to be shown. This stop videos from playing in some circumstances. Some browsers appear to access the video directly for streaming, instead of going through http-auth (such as Brave on mobile). That's what is making me think this is an `upgrade-insecure-request` issue.

F1LT3R

Note: this behavior is not reproducible with images like `.png` or `.jpg`. Possibly related: https://stackoverflow.com/questions/4840413/why-will-mp4-video-not-work-when-http-basic-authentication-enabled https://github.com/google/ExoPlayer/issues/4760 https://codybonney.com/serving-media-files-to-mobile-safari-behind-basic-http-authentication/