W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: Sending Referer [#144]

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 8 Jun 2009 09:20:48 +1000
Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <31D2D597-1250-4E97-9435-3C861B29E631@mnot.net>
To: Adam Barth <w3c@adambarth.com>
I'm not crazy about this approach, but it may be workable.

p2 section 9.6 is currently:

>    The request-header field "Referer" [sic] allows the client to
>    specify, for the server's benefit, the address (URI) of the  
> resource
>    from which the request-target was obtained (the "referrer",  
> although
>    the header field is misspelled.)  The Referer request-header  
> allows a
>    server to generate lists of back-links to resources for interest,
>    logging, optimized caching, etc.  It also allows obsolete or  
> mistyped
>    links to be traced for maintenance.  The Referer field MUST NOT be
>    sent if the request-target was obtained from a source that does not
>    have its own URI, such as input from the user keyboard.
>
>      Referer        = "Referer" ":" OWS Referer-v
>      Referer-v      = absolute-URI / partial-URI
>
>    Example:
>
>      Referer: http://www.example.org/hypertext/Overview.html
>
>    If the field value is a relative URI, it SHOULD be interpreted
>    relative to the request-target.  The URI MUST NOT include a  
> fragment.
>    See Section 11.2 for security considerations.


Based on discussion so for, here's a straw-man:

"""
The request-header field "Referer" [sic] allows the client to specify,  
for the server's benefit, the address (URI) of the resource from which  
the request-target was obtained (the "referrer", although the header  
field is misspelled.).

The Referer request-header allows servers to generate lists of back- 
links to resources for interest, logging, optimized caching, etc. It  
also allows obsolete or mistyped links to be traced for maintenance.  
Some servers use Referer as a means of controlling where they allow  
links from (so-called "deep linking"), but it should be noted that  
legitimate requests are not required to contain a Referer header field.

If the request-target was obtained from a source that does not have  
its own URI (e.g., input from the user keyboard), the Referer field  
MUST either be sent with the value "about:blank", or not be sent at  
all. Note that this requirement does not apply to sources with non- 
HTTP URIs (e.g., FTP).

   Referer        = "Referer" ":" OWS Referer-v
   Referer-v      = absolute-URI / partial-URI

Example:

   Referer: http://www.example.org/hypertext/Overview.html

If the field value is a relative URI, it SHOULD be interpreted  
relative to the request-target. The URI MUST NOT include a fragment.  
See Section 11.2 for security considerations.
"""



On 02/06/2009, at 7:14 AM, Adam Barth wrote:

> On Mon, Jun 1, 2009 at 12:14 PM, Julian Reschke  
> <julian.reschke@gmx.de> wrote:
>> Adam Barth wrote:
>>> On Mon, Jun 1, 2009 at 11:40 AM, Adam Barth <w3c@adambarth.com>  
>>> wrote:
>>>> With regards to the 'null' value, we should try to pick a value  
>>>> that's
>>>> friendly to regular expressions (i.e., avoids . / [ and similar
>>>> characters) because many web application firewalls (who would use  
>>>> this
>>>> value) express their rules in terms of regular expressions.
>>>
>>> One possible value we could use is
>>>
>>> about:blank
>
> [...]
>
>>> about:noreferrer
>>
>> That will be tricky to use, as it would be a downref to a Proposed  
>> Standard
>> (*). HTTPbis will be (at least) one step ahead on the standards  
>> ladder).
>
> We need only suggest (require?) the literal "about:blank" without a
> downref.  That is syntactically an absolute URI, and the use should
> not conflict with any other use of that sequence of bytes.
>
> Adam
>


--
Mark Nottingham     http://www.mnot.net/
Received on Sunday, 7 June 2009 23:21:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:03 GMT