在什么情况下，HTTP引荐来源网址将被截断 [英] In what cases HTTP referer will be truncated
问题描述
我试图了解HTTP引用标头的行为.我注意到有时引荐来源网址是完整的(完整的URL，包括路径和查询字符串)，但大多数情况下仅包含域.
例如，以" https://www.google.com/"代替"解决方案
浏览器会根据需要的标准使用 我们在网络上到处看到的信息"一词都有一个附加的信息安全概念，并且HTTP标头没有什么不同.根据标头携带的信息类型，服务器可以指定需要使用的引用策略的类型.这是W3中的引荐来源网址政策 有关每个功能的详细信息，请参见上面的引荐来源网址"政策链接. 举个例子；使用谷歌搜索黄页".在这种情况下 引荐来源: https://www.google.ie/ 推荐人政策:来源 生成的URL: https://www.google.ie/gen_204?atyp=i&ct=&cad=udla=3&ei=x65kGDkdyKGHDkF0KeoBg&e=12&zx=1494785478502 链接到第一个结果是 实际网址为 https://www.goldenpages.ie/ 当我们实际单击链接引用链接时，将更改为 引荐来源网址: https://www.goldenpages.ie/，引荐来源网址政策为 推荐人政策:降级时不推荐人 这意味着，如果我们单击当前页面上的另一个链接，我们将看不到与在Google搜索结果页面的URL中看到的参数相似的所有其他参数. 要证明是这种情况；单击当前页面上的任何链接，并查看引荐来源标头根据策略类型的变化(如果使用开发人员工具并检查网络活动，则可以在关联的js文件中找到 当我单击列出您的公司"链接引荐来源网址时，保持不变 https://www.goldenpages.ie/list-your-business/ 且未传递其他任何参数 所以只是整理一下这个凌乱的解释；生成的URL取决于为引荐来源网址"策略设置的规则，这些规则可以是没有参数的简单基本规则，也可以是包含与用户和导航来源有关的大量信息的非常长的URL. 注意:URL无效，我弄乱了一些字母. I'm trying to understand the behavior of HTTP referer header. I noticed that sometimes the referer is full (full URL, including path and query string) but mostly it includes the domain only. For example 'https://www.google.com/' instead of 'https://www.google.com/search?q=http+referer+truncated&oq=http+referer+truncated&aqs=chrome..69i57.6485j0j1&sourceid=chrome&ie=UTF-8#q=http+referer+is+not+full' Are there any rules as to when the refere and is full and when it's truncated? HTTP referrer headers are created by browsers according to desired criteria using Referrer Policy even though there is a general standard used by majority of the browsers there are some differences about how the browsers handles the servers instructions, mainly mobile web browsers are the ones which does not cooperate nicely with WWWC recommendations on this matter. So why is there need for different HTTP referrer headers? To understand this we need to look at what are these headers are used for first. Main purpose in its simplest form is "carrying information from the originating page to the new page". Everywhere we see the word "information" in the web there is a information security concept attached to it and HTTP header is no different. Depending on what kind of information headers carry, server can specify the type of referrer policy needs to be used. Here is the list of referrer policies from W3 Detailed information about each of these are available in the Referrer policy link i included above. To give an example;
Using google searching for "Yellow Pages". in this case origin:https://www.google.ie referer:https://www.google.ie/ Referrer Policy:origin generated URL:https://www.google.ie/gen_204?atyp=i&ct=&cad=udla=3&ei=x65kGDkdyKGHDkF0KeoBg&e=12&zx=1494785478502 link to the first result is While the actual URL is https://www.goldenpages.ie/ When we actually click the link referrer changes to Referer:https://www.goldenpages.ie/ and the referrer policy is Referrer Policy:no-referrer-when-downgrade This means if we click another link from the current page we won't see all the additional parameters similar to the ones we saw in the URL from google search results page. To prove this is the case; click any link from the current page and watch the referrer header changing according to the the policy type (Which can be found in the associated js file if you use developer tools and inspect the network activity) When i click the "List your business" link referrer stay as https://www.goldenpages.ie/list-your-business/ and no other parameters are passed So just to tidy up this messy explanation; What URL gets generated is dependent on what rules are set regarding to Referrer policy may that be a simple base rule with no parameters or a very long URL with loads of information relating to the user and origin of the navigation. Note: URLs wont work i have jumbled some letters. 这篇关于在什么情况下，HTTP引荐来源网址将被截断的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！枚举ReferrerPolicy {"，无推荐人"，降级时无推荐人"，原产地"，起源"，严格起源"，起源于交叉起源"，严格起源于交叉起源"，不安全网址"}; enum ReferrerPolicy {
"",
"no-referrer",
"no-referrer-when-downgrade",
"same-origin",
"origin",
"strict-origin",
"origin-when-cross-origin",
"strict-origin-when-cross-origin",
"unsafe-url"
};
