> This works because site B has no control over the Referer that
site A
> sends. It does not work perfectly (you have to account for
browsers that
> don't send referer), but it works well enough, because third
parties
> can't control how your browser sends Referer headers. If you give
> programmatic control of the Referer to site B, you allow them to
bypass
> such mechanisms.
Except of course you only allow them if there's some hypothetical
cross
domain XHR, something which doesn't exist,
AIUI that's under discussion in a TF now.
and then usefully there's a way
of taking an XHR stream and converting it to an image or video
stream, again
something that doesn't exist.
You're losing me here; how do "image or video streams" come into it?
> Most browsers today (the only exception I've seen yet is
Mozilla) send
> Referer from XMLHttpRequest; by explicitly disallowing it from
being
> automatically set, you're diverging from the current model for
XHR, as
> well as diverging from the model for normal browser operation.
I don't want to specifically disallow it, I don't want it to be
MUST, nor do
I see a particular reason for it not to be overridable - a browser
may want
to not allow it to be overridable without specific user agreement
outside
of the same domain for such reasons, but I don't see the reason for
disallowing it from overriding within the same domain - given that
any cross
domain is with the explicit agreement of the user in all
implementations
today, I don't see the problem with any of them setting it, indeed
I have
many use cases for it.
OK. I've made my case and have heard from some individuals; it seems
like there's agreement that automatically setting Referer shouldn't
be disallowed, but disagreement about whether it should be
overridable. I'd like to hear the WG's opinion on the matter.
The most prominent being the same Accessibility Testing assistant
mentioned
elsewhere.
ref?
Cheers,
--
Mark Nottingham
[EMAIL PROTECTED]
