Fyi: This change has been made in chrome.
* respect no-store headers for cross-origin resources (only for HTTPS)
* allow HTTPS cross-origin resources to be listed in manifest hosted on
HTTPS
On Mon, Feb 14, 2011 at 5:04 PM, Michael Nordman micha...@google.comwrote:
Fyi... I'm planning on making
Fyi... I'm planning on making a change along these lines to chrome soon...
* respect no-store headers for cross-origin resources
* allow HTTPS cross-origin resources
On Tue, Feb 8, 2011 at 3:25 PM, Michael Nordman micha...@google.com wrote:
Hi again,
Just had an offline discussion about this
Hi again,
Just had an offline discussion about this and I think the answer can
be much simpler than what's been proposed so far. All we have to do
for cross-origin HTTPS resources is respect the cache-control no-store
header.
Let me explain the rationale... first let's back up to the motivation
On Fri, 04 Feb 2011 23:15:44 +0100, Michael Nordman micha...@google.com
wrote:
Just want to wake this thread up and say that I still see CORS as a
good fit for this use case, and I'm curious Jonas about what you think
in light of my previous post?
I think Jonas does have a point. There are
On Mon, Feb 7, 2011 at 6:18 AM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 04 Feb 2011 23:15:44 +0100, Michael Nordman micha...@google.com
wrote:
Just want to wake this thread up and say that I still see CORS as a
good fit for this use case, and I'm curious Jonas about what you think
On Mon, Jan 31, 2011 at 6:27 PM, Michael Nordman micha...@google.com wrote:
But... the risk you outline is not possible...
However, with the modification you are proposing, an attacker site
could forever pin this page the users app-cache. This means that if
there is a security bug in the
On Mon, 7 Feb 2011, Jonas Sicking wrote:
On Mon, Jan 31, 2011 at 6:27 PM, Michael Nordman micha...@google.com wrote:
But... the risk you outline is not possible...
However, with the modification you are proposing, an attacker site
could forever pin this page the users app-cache. This
On Mon, Feb 7, 2011 at 3:27 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Jan 31, 2011 at 6:27 PM, Michael Nordman micha...@google.com wrote:
But... the risk you outline is not possible...
However, with the modification you are proposing, an attacker site
could forever pin this page the
On Mon, Feb 7, 2011 at 3:31 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 7 Feb 2011, Jonas Sicking wrote:
On Mon, Jan 31, 2011 at 6:27 PM, Michael Nordman micha...@google.com wrote:
But... the risk you outline is not possible...
However, with the modification you are proposing, an attacker
On Mon, Feb 7, 2011 at 4:35 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Feb 7, 2011 at 3:31 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 7 Feb 2011, Jonas Sicking wrote:
On Mon, Jan 31, 2011 at 6:27 PM, Michael Nordman micha...@google.com
wrote:
But... the risk you outline is not
Hi again,
Just want to wake this thread up and say that I still see CORS as a
good fit for this use case, and I'm curious Jonas about what you think
in light of my previous post?
-Michael
On Mon, Jan 31, 2011 at 6:27 PM, Michael Nordman micha...@google.com wrote:
But... the risk you outline is
I don't fully understand your emphasis on the implied semantics of a
CORS request. You say it *only* means a site can read the response. I
don't see that in the draft spec. Cross-origin XHR may have been the
big motivation behind CORS, but the mechanisms described in the spec
appear agnostic with
On Mon, Jan 31, 2011 at 2:57 PM, Michael Nordman micha...@google.com wrote:
I don't fully understand your emphasis on the implied semantics of a
CORS request. You say it *only* means a site can read the response. I
don't see that in the draft spec. Cross-origin XHR may have been the
big
But... the risk you outline is not possible...
However, with the modification you are proposing, an attacker site
could forever pin this page the users app-cache. This means that if
there is a security bug in the page, the attacker site could exploit
that security problem forever since any
On Thu, Jan 27, 2011 at 8:30 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jan 27, 2011 at 5:16 PM, Michael Nordman micha...@google.com wrote:
A CORS based answer to this would work for the folks that have
expressed an interest in this capability to me.
cc'ing some other appcache
On Fri, Jan 28, 2011 at 2:13 PM, Michael Nordman micha...@google.com wrote:
On Thu, Jan 27, 2011 at 8:30 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jan 27, 2011 at 5:16 PM, Michael Nordman micha...@google.com wrote:
A CORS based answer to this would work for the folks that have
A CORS based answer to this would work for the folks that have
expressed an interest in this capability to me.
cc'ing some other appcache implementors too... any thoughts?
On Wed, Jan 26, 2011 at 12:28 PM, Michael Nordman micha...@google.com wrote:
I was alluding to a simple robots.txt like
On Thu, Jan 27, 2011 at 5:16 PM, Michael Nordman micha...@google.com wrote:
A CORS based answer to this would work for the folks that have
expressed an interest in this capability to me.
cc'ing some other appcache implementors too... any thoughts?
CORS has the semantics of you're allowed to
On Tue, 25 Jan 2011 23:37:55 +0100, Michael Nordman micha...@google.com
wrote:
Would the public-webapps list be better for discussing appcache
feature requests?
It's not a feature drafted in any of the WebApps WG specifications. If you
want to discuss at the W3C the appropriate place would
I was alluding to a simple robots.txt like solution with the static
'allow' file, but it seems like CORS could work too, it is more
burdensome to setup due to the additional HTTP headers.
GET /some-resource
Origin: https://acme.com
HTTP/1.x 200 OK
Access-Control-Allow-Origin: * |
Would the public-webapps list be better for discussing appcache
feature requests?
This could be as simple as the presence of an
'applicationcaching_allowed' file at the top level. An https manifest
update that wants to retrieve resources from another https origin
would first have to fetch the
AppCache feature request: An https manifest should be able to list
resources from other https origins.
I've got some app developers asking for this feature. Currently, it's
explicitly disallowed by the the spec for valid security reasons, but
there are also valid reasons to have this capability,
22 matches
Mail list logo
