我与我的团队就使用HttpRequest.UrlReferrer进行了一次有趣的讨论，并希望征求社区的反馈意见。根据{{3}}：
Referer [sic] request-header字段 允许客户端指定 服务器的好处，地址（URI） 从哪个资源 获得了Request-URI（ “引用者”，虽然是标题字段 拼写错误。）The Referer request-header允许服务器 生成反向链接列表 感兴趣的资源，伐木， 优化的缓存等。它也允许 过时或错误的链接 跟踪维护。推荐人 如果是，则不得发送字段 Request-URI是从源获得的 这没有自己的URI 作为用户keyboard.as从用户键盘输入的输入。
Request.UrlReferrer对象执行将包含格式良好的URI的引用字符串转换为每个请求都具有属性的对象的工作。
根据我们的日志，有些请求包含引用中的无效数据，例如：
localhost
app:/BeamBackTest.swf
app:/multtiple.swf
app:/AFriendFeed.swf
ALToolBar
app:/index.html
mhtml:file://C:\Documents+and+Settings\User\Desktop\oracle\What+is+a+View+in+Oracle+-+Stack+Overflow.mht
使用Request.UrlReferrer意味着上述情况将为NULL。通过使用Request.UrlReferrer丢弃基于W3C规范的无效数据或使用Request.ServerVariables [“HTTP_REFERER”]保留它是否更好，即使数据可能有趣，但可能无用。
答案 0 :(得分：2)
嗯，这取决于你对数据的处理方式。如果你正在做一些需要有效URI的事情，那么你也可以使用Request.UrlReferrer，因为你必须将其剥离。但是，如果您正在做的只是记录它，并且您的日志工具可以处理奇怪的事情，我建议使用第二种方法 - 特别是对于app：/ data，这可能会产生有用的模式。
答案 1 :(得分：1)
它的主观性基于您的需求。我们存储所有东西，即使它的垃圾。有一天，我们可能知道如何更好地处理它，它将不再是垃圾。如果我们没有存储它，因为当时我们无法理解它，我们永远无法将其恢复。