referer header on <meta http-equiv="refresh" content="0;url=">

[wanderview]

I've been investigating an compat issue in firefox:

https://bugzilla.mozilla.org/show_bug.cgi?id=1454022

The demo referenced there is doing an OAUTH dance with twitter and looking for a referer header to detect when things are passed back. Twitter does a <meta http-equiv="refresh"> to "redirect" back to the original site's URL.

The incompatibility is in how different browsers set the referer header on the meta refresh:

• Chrome sets the URL of the document containing the meta refresh element.
• Safari sets the URL of the document containing the meta refresh element.
• Edge sets the referer URL used to create the document containing the meta refresh element. So its trying to simulate what a normal redirect does where the referer is copied instead of setting the redirecting URL as the referer.
• Firefox does not set any referer header, but internally has logic matching edge's behavior.

AFAICT the html spec doesn't say what to do with the referer when calling out to fetch API for meta refresh. So I believe that would result in a referer of client that would then map to chrome/safari behavior.

What is intended or desired behavior here?

See also: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28339

[wanderview]

Oh, I also made a demo to help test this:

https://meta-refresh-referer.glitch.me/

To see the edge behavior load the test with something like "?foo=bar" on the URL so you can distinguish from origin strings.

[wanderview]

I'm inclined to align firefox with chrome and safari here. Its not truly a redirect and trying to magically treat it like one seems error prone. Since Firefox is not providing a referer header it seems like doing this should have minimal compat risk.

Its unclear to me, though, if edge could follow without breaking some legacy sites depending on their current referer behavior.

[zrhoffman]

AFAICT the html spec doesn't say what to do with the referer when calling out to fetch API for meta refresh. So I believe that would result in a referer of client that would then map to chrome/safari behavior.

As specified, the Refresh header requires a Document in order to work, so it does not affect subresources.

@annevk added WPT coverage for this in web-platform-tests/wpt#6606: https://wpt.live/html/browsers/browsing-the-web/navigating-across-documents/refresh/subresource.any.html

I'm inclined to align firefox with chrome and safari here. Its not truly a redirect and trying to magically treat it like one seems error prone. Since Firefox is not providing a referer header it seems like doing this should have minimal compat risk.

Aligning Gecko with WebKit seems reasonable to me. ICBW, but the only difference I'm noticing between WebKit and Blink behavior WRT the referrer from refresh is that Blink sends the full URL for cross-origin requests in an iframe with referrer policy no-referrer-when-downgrade or unsafe-url, while WebKit only sends the origin for these referrer policies.

[zrhoffman]

Firefox now ships sending a Referer header from <meta http-equiv=refresh>.

ICBW, but the only difference I'm noticing between WebKit and Blink behavior WRT the referrer from refresh is that Blink sends the full URL for cross-origin requests in an iframe with referrer policy no-referrer-when-downgrade or unsafe-url, while WebKit only sends the origin for these referrer policies.

This referrer trimming is an intentional privacy feature, and Firefox does it, too. This behavior is under discussion in privacycg/proposals#13 (and was discussed previously in w3c/webappsec-referrer-policy#125 and w3c/webappsec-referrer-policy#142).

Because Chrome, Safari,and Firefox are in agreement WRT sending Referer from refreshes, and because the HTML spec already specifies this behavior, #3643 can probably be closed.