Closed yi-gu closed 1 year ago
After some discussion internally, we'd like to better understand the rationale of the change. i.e. why origin
is a better choice in this case?
The FedCM spec explicitly states that the referrer is set to the "origin" (aka with no path), so the potential risk of "referrer could expose path with certain policy (e.g. no-referrer-when-downgrade
)" does not seem to be a real concern.
@bvandersloot-mozilla could you please shed some light here?
I don't recall there being a reason thatReferer
header would be better than Origin
. Without that reasoning, we should try to use Origin
. It is a more modern concept and its semantics agree with the value we have. Also, on a minor note, some middleboxes tamper with the Referer
header, and that was part of the reasoning for the introduction of Origin
IIRC.
@annevk was there any other reason we missed? Unfortunately we forgot the reason mentioned in the discussion.
So, IIUC, we're talking here about non-CORS requests having the Origin header instead of a Referrer. Can y'all outline the reasoning for this? Also, are there any precedents for this?
At least in the past, I've seen servers that use the Origin header to distinguish CORS from non-CORS headers (e.g. to decide if they need to send ACAO, maybe for other things). Are we sure that sending Origin headers on non-CORS requests won't cause weird side-effects?
Chrome pioneered using the Origin
header outside of CORS for CSRF @yoavweiss (without much of a specification at the time), so... (This only got standardized properly in the last couple of years in Fetch by someone at Mozilla.)
@bvandersloot-mozilla lists the reason, which is also the reason we have Origin
to begin with. Referer
got stripped by middleware, so Origin
is a more reliable signal.
With Referer
you also run into questions around browser preferences and Referrer Policy.
OK, thanks!
Ping here. I think it would be important to clarify this in the spec.
As agreed in issue 230, we should send Origin instead of Referer: