On Aug 1, 2011, at 10:29 AM, Hill, Brad wrote:
> The ability to do all of these things server-side, with referrer checking,
> has been universally available for fifteen years. (RFC 1945)
>
> In every one of the use cases below, From-Origin is a worse solution than
> referrer checking. What
On Jul 31, 2011, at 5:52 PM, Bjoern Hoehrmann wrote:
> * Anne van Kesteren wrote:
>> http://www.w3.org/TR/from-origin/
>
> The proposed `From-Origin` header conveys a subset of the information
> that is already available through the Referer header.
From-Origin is a response header and Referer
should we expect it to become universally deployed where referrer checking is
not?
-Brad
From: rocalla...@gmail.com [mailto:rocalla...@gmail.com] On Behalf Of Robert
O'Callahan
Sent: Monday, August 01, 2011 6:16 AM
To: Hill, Brad
Cc: Anne van Kesteren; WebApps WG
Subject: Re: From-Origin FPW
On Thu, Jul 28, 2011 at 12:44 PM, Hill, Brad wrote:
> What are the use cases where a user is better off if their browser obeys
> From-Origin than if it does not?
>
> Bandwidth "theft"? The user wants to see the image. The problem, such
> that one exists, is for the hosting server. They can and
* Anne van Kesteren wrote:
> http://www.w3.org/TR/from-origin/
The proposed `From-Origin` header conveys a subset of the information
that is already available through the Referer header. As it is, it is
very rare for the Referer header, or coressponding interfaces that are
available to scripts,
I'm still not convinced that implementing this as a feature of the User Agent
benefits the user or is the most appropriate technology for addressing the
problem statements in the specification.
What are the use cases where a user is better off if their browser obeys
From-Origin than if it does
-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Anne van Kesteren
Sent: Friday, July 22, 2011 8:09 AM
To: WebApps WG
Subject: From-Origin FPWD
Hi,
The WebApps WG published the From-Origin header proposal as FPWD:
http://www
On Fri, 22 Jul 2011 22:47:59 +0200, Jonas Sicking wrote:
It seems to me like this feature heavily overlaps with CORS. In fact,
it addresses the exact same cases, except that it does it for
resources which we for various reasons use
allow-embedding-but-not-reading cross site.
Would it make more
It seems to me like this feature heavily overlaps with CORS. In fact,
it addresses the exact same cases, except that it does it for
resources which we for various reasons use
allow-embedding-but-not-reading cross site.
Would it make more sense to simply add this into CORS?
/ Jonas
On Fri, Jul 22
I recommend reading the relevant Internet-Draft:
http://tools.ietf.org/html/draft-gondrom-frame-options-01
The draft formalizeds X-Frame-Options as Frame-Options. The issue is on the
side of the headers' technical design.
Regards,
--
Thomas Roessler, W3C(@roessler)
On Jul 22,
In my opinion, we should not be supporting X-* headers any more than
absolutely necessary, so phasing out X-Frame-Options in preference of
From-Origin would be the correct way to go. I'm aware this does mean a
cross-over period where servers are likely to have to provide both
headers, and it might
The web...@ietf.org mailing list would probably be an appropriate place for
discussion about x-frame-options.
(It's right now an individual internet draft.)
--
Thomas Roessler, W3C(@roessler)
On Jul 22, 2011, at 17:43 , Arthur Barstow wrote:
> On 7/22/11 11:08 AM, ext Anne van Kestere
On 7/22/11 11:08 AM, ext Anne van Kesteren wrote:
The WebApps WG published the From-Origin header proposal as FPWD:
http://www.w3.org/TR/from-origin/
The main open issue is whether X-Frame-Options should be replaced by
this header or should absorb its functionality somehow.
Anne - what lis
13 matches
Mail list logo
