- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 10 Feb 2008 11:42:47 +0100
- To: Ian Hickson <ian@hixie.ch>
- CC: "public-html@w3.org" <public-html@w3.org>
Ian Hickson wrote: >>> As noted by others, no Referer header is treated as a local Referer >>> header, which makes it susceptible to XSRF. >> Not sure what a "local" referer header would be. >> >> I'm not sure which mail you are referring to (pointer, please), is it >> <http://lists.w3.org/Archives/Public/public-html/2008Feb/0014.html>? > > Yes, that describes the problem. By "local" referrer I mean one that > specifies a page with the same origin as the target URI. So you're saying that recipients treat the absence of a Referer header as indication the offering page was from the same origin? That would IMHO be contrary to what RFC2616 defines (the absence of the Referer header means that the Referrer either doesn't have a URI, or the client doesn't want to reveal it). Pointers, please. >>>> Kornel wrote: >>>>> Another advantage of headers is that Apache could log pings without help >>>>> of any scripts or non-standard modules - LogFormat directive allows >>>>> logging of arbitrary headers. >>>> I'm not sure how this is relevant... >>> It seems extremely relevant, as it enables cheap server-side use >>> instead of requiring heavy lifting for the author. >> For the author? > > Indeed. How is the author affected? >> It seems the additional work would be for the implementor of the web >> server, implementing a module for ping tracking. I'm not sure why that's >> considered a major issue. > > There's no additional work required. As Kornel explained in the text > quoted above, one can already use Apache for this. What I said is that not using headers would require additional work for the server implementor; and I think that's not a problem if it avoids abusing existing headers. >> The risk is that recipients that expect a compliant Referer header will >> break in some way. > > Can you provide concrete examples of such servers? No. But there is a risk when you extend the value range to include things that were not allowed before. >>>> Could you please state what problem you are trying to solve, and why >>>> it needs to involve the Referer header? >>> I believe the problem has been stated a number of times in this thread >>> already. I refer you to dolphinling's original e-mail. >> Pointer, please. > > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-January/013637.html I admit I don't understand that description. Is this based on the (IMHO incorrect) assumption that the absence of a Referer header indicates a local request? >> My concern is that you're raking ease of implementation higher than >> consistency of specifications. > > Yes, absolutely. Indeed it's one of our principles: > > http://www.w3.org/TR/html-design-principles/#priority-of-constituencies > > Interoperability and compatibility with existing deployed servers is > orders of magnitude more important to me than pedantic compliance to other > specifications. Specifications exist to help move civilisation forward, > not to provide arbitrary restrictions on progress. When a specification > gets in the way of improving the Web, it should be changed or displaced. I think you're reading something into the design principle it doesn't say. Creating conflicts between specs is a principle problem; of course you could assign a "cost" to that, but in that case I'd argue the "cost" of having one spec being in conflict with another is much higher than some additional implementation work on the server. Of course, YMWV and I expect it does. BR, Julian
Received on Sunday, 10 February 2008 10:43:12 UTC