Bring SecurityPolicy::GenerateReferrer in sync with //content
Currently, we have three places where we compute requests' referrers, nominally according to [1, Algorithm 8.1]. This change makes a couple alterations to SecurityPolicy::GenerateReferrer (one of the places) to bring it in line with the behavior in content::Referrer::SanitizeForRequest (another implementation of the algorithm). After this change, SecurityPolicy::GenerateReferrer will: - truncate requests with referrers longer than 4096 bytes to the initiating origin, as specified in [1, Alg. 8.1, step 6]; - strip URLs for use as referrers as part of the referrer generation process [step 4]; and - explicitly return "no referrer" when given an invalid URL (motivation: this will align the behavior with the other two implementations of the algorithm once they also strip URLs for use as referrers as part of the referrer generation process, because this is how GURL::GetAsReferrer behaves). In order to implement the second of these in a manner consistent with the non-Blink code, this change alters KURL's referrer stripping logic to move from "return a default value if the URL is not http(s)" to "return a default value if the scheme is not suitable for use in a referrer", bringing it in line with GURL::GetAsReferrer. [1]: https://w3c.github.io/webappsec-referrer-policy/#parse-referrer-policy-from-header Bug: 1094526 Change-Id: I515fd9e832e99c1fdd2ca207560b865d06edc39c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2246987Reviewed-by:Tom Sepez <tsepez@chromium.org> Commit-Queue: David Van Cleve <davidvc@chromium.org> Cr-Commit-Position: refs/heads/master@{#781386}
Showing
Please register or sign in to comment