On Wed, Jun 24, 2009 at 8:57 PM, Adam Barth<w...@adambarth.com> wrote:
> On Wed, Jun 24, 2009 at 8:50 PM, Bil Corry<b...@corry.biz> wrote:
>> Continuing your example, if XHTML defines requests from <form> as 
>> privacy-sensitive, then the UA will have two different behaviors for 
>> Sec-From, depending on if it's rendering HTML5 or XHTML?
> That's correct.  Hopefully folks writing specs at the application
> layer will coordinate so as not to make the web platform any more
> confusing than it is already.  :)

To make it clear what the intent is here:

We know that people are building web applications where GET requests
cause state changes on the server side. While this is unfortunate, we
don't believe that people will stop.

Thus we sometimes want Sec-From to be included in GET requests.

At the same time, it's a quite common practice on the web today for
sites to allow other users to put <a href="..."> links on their site.
For example discussion boards often detect addresses and turn them
into links, some, such as wikipedia, even allow users to hide which
url the link is going to by specifying an arbitrary text for the link.
In these cases we don't want the person inserting the link to be able
to "speak for" the site the link was located on.

Additionally, one of the reasons why the "referer" (sic) header is
being so frequently blocked is that it leaks information about where
users are coming from. For example when a political website linking to
google.com it has bothered many users that this tells google my
political affiliation, causing them to filter the referer header.

Thus in these two cases we don't want the GET request to include a
Sec-From header containing the originating website.

The difference between these two cases is purely in the context from
which the GET request was created. While we could enumerate these
contexts in Adams spec, IETF has in the past expressed a dislike for
specifying application behavior, prefering only to define protocol
behavior. Thus we have to define the protocol in an IETF spec, and
allow HTML5 (or some other spec) to selectively invoke the different
behaviors defined by the IETF spec.

/ Jonas

Reply via email to