- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 2 Jun 2009 01:50:11 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Adam Barth <w3c@adambarth.com>
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/144> There are some aspects of #144 that should be easy; e.g., clarifying that sending Referer isn't dependent of the protocol of the source. However, in previous discussions, Adam et al indicated that it would be interesting to require that Referer always be sent, by minting a new value (e.g., 'null', although it will have to be something else, since "null" is a valid partial-URI) to indicate when a Referer is not available. I see a few potential problems here... 1) Currently the draft (and 2616) says "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." We'd have to remove this requirement and say something like "The Referer field MAY be sent with the "null" value if the request-target..." SHOULD or MUST isn't possible here, because existing clients would become non-conformant. Technically, a server could have a problem with the 'null' value (as well as the fact that there isn't a referer, but the header is being sent), but it seems doubtful that this will cause an issue in practice... 2) A new requirement would need to be added to make the referer field compulsory, but again this would make some existing clients non- conformant. Purely within HTTPbis, I think the best we could do, then, would be to add a null value that can be sent when appropriate, and encourage UAs to send referer. However, there's nothing stopping a third party document (e.g., a W3C browser profile) from requiring that it be sent... Adam, what do you think? Others? Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Monday, 1 June 2009 15:50:50 UTC