RE: The HTTP Origin Header (draft-abarth-origin)

(cutting down distribution list)

Treating Referer like some kind of urban blight which we just leave to
molder seems odd to me. Is Referer deprecated? Expected to be sent as well,
but then frequently stripped? If the main difference between "Referer" and
"Origin" is that Referer contains too much information or is sent at the
wrong time, why not just fix "Referer"? It shouldn't be any harder to change
an existing header (compatibly) than it is to invent a new one.

For example, you could normalize Referer paths, use a different URI scheme,
replace the path (or even host name) with a different string (e.g., the hash
of the original), without introducing a new header. 

I think the discussion confuses the cost/benefits for different
constituencies. There are perhaps six categories:  implementers and
users/operators of browsers, firewall/gateway/proxies, web sites. 

* Browser makers:   Yay!
* Browser users: ? sounds confusing ? Is this like cookies? Don't they carry
viruses?
* Firewall makers:  Origin blocking! New feature! Oh boy!
* Firewall admins:  Low benefit (not on enough sites). Not blocking it might
cost me! (reveal host names)
* Server makers:   Roy sees no benefit, not worth the time.
* Server operators: doesn't solve problem until implementing browser share
is substantial.

You can't benefit browser users until a significant number of server
operators deploy this. But server operators will be reluctant to deploy
without browser implementation. Meanwhile, if firewalls start blocking the
header, then the benefit curve will go down, not up, and it will be another
set of useless bytes sent over the wire only to be parsed and blocked later
(i.e., just more cost).

Larry

Received on Tuesday, 27 January 2009 01:42:30 UTC