Stop storing "referer" header to blink::ResourceRequest |
||||||||
Issue descriptionblink::ResourceRequest::SetHTTPReferrer stores the information as the "referer" header. But when it's converted to a network::ResourceRequest, that header gets ripped off (see HttpRequestHeadersVisitor::VisitHeader). Instead, the referrer information is set to network::ResourceRequest::referrer. This is very confusing. Probably we need to have the referrer information in blink::ResourceRequest as a separate member (e.g., blink::ResourceRequest::referrer_).
,
Jun 8 2018
Yes, thank you. I'll link to my current doc right now, which is still a WIP. Appreciate you filing this. https://docs.google.com/document/d/1s2bSTktwijQVVBqXi7LIP5zuerR-p3ZRusa6VKLYqMY/
,
Jun 8 2018
,
Jun 8 2018
,
Jun 8 2018
,
Jun 8 2018
,
Jul 10
Looks like the `Referer` "header" stored on blink::ResourceRequest is getting ripped off and treated specially in [1], where `referrer_url` is the `Referer` HttpHeaderField on a blink::WebURLRequest, which is sourced from its underlying blink::ResourceRequest. As stated, makes sense to have a blink::ResourceRequest::referrer that gets referenced here as a regular member and not in this way. [1]: https://cs.chromium.org/chromium/src/content/renderer/loader/web_url_loader_impl.cc?sq=package:chromium&g=0&l=649
,
Jul 19
,
Dec 10
Can you tell me the status of this bug?
,
Dec 10
Blocked on me getting some time to finish it up is all, sorry for the delay.
,
Dec 10
A more "technical" status: most consumers of ResourceRequests are using blink::ResourceRequest::SetReferrer{String, Policy}, but under the hood we're still storing it as an HTTP header (in these cases, this is done at the BaseFetchContext level).
Soon we'll stop storing as a header on blink::RR, and modify content/ level things to consume it that way.
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by yhirano@chromium.org
, Jun 8 2018