Open Bug 1479017 Opened 6 years ago Updated 2 years ago

No referer header sent on http-header: Refresh

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Version:
61 Branch
Type:
defect

Tracking

()

Project Flags:
Webcompat Priority P2

People

(Reporter: misha.stepanov, Unassigned)

References

Details

(Keywords: parity-chrome)

Attachments

(1 file)

app.js
(deleted), application/x-javascript
Details
Attached file app.js (deleted) —
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:61.0) Gecko/20100101 Firefox/61.0 Build ID: 20180704003137 Steps to reproduce: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:61.0) Gecko/20100101 Firefox/61.0 If server returns Refresh header (for example Refresh: 4; url=https://bugzilla.mozilla.org) then no referer header from the client to this refresh page is sent. Expected results: on chrome currentPage header is sent to server I expect to see the same behavoiur on FF.
Component: Untriaged → Document Navigation
Keywords: parity-chrome
Product: Firefox → Core
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=266554, https://bugzilla.mozilla.org/show_bug.cgi?id=1324860
Any idea what we're supposed to be doing here?
Flags: needinfo?(annevk)
Pretty sure that per the HTML standard there should be a Referer header as the navigate algorithm (which Refresh ends up using) creates a normal request which ends up with a non-empty referrer field (which uses some global state to get the eventual value).
Flags: needinfo?(annevk)
Severity: normal → S3

This bug is breaking Twitch Extension's authentication flow, preventing people from adding extensions to their Twitch channel. Twitch is, at the end of their OAuth flow, using

<meta http-equiv="refresh" content="0;URL='...'" />

to redirect the user to a different page, and they expect a referrer to be set. If they don't see their own referrer, they set X-Frame-Options: SAMEORIGIN in the response, and that then breaks the auth flow. See this web-bug comment for details.

I assume Twitch will not change their behavior here, as this authentication-flow has some security aspects to it. And since this is possibly hard to workaround, this is probably not a P5... Nominating this for our webcompat triage meeting next Monday.

Webcompat Priority: --- → ?
See Also: → https://github.com/webcompat/web-bugs/issues/117221

Based on :denschub's comments above it seems like this is now breaking a major site, so we probably need to retriage the bug.

Priority: P5 → --
Webcompat Priority: ? → P2
Status: UNCONFIRMED → NEW
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: