On Tue, 17 Mar 2009 21:50:21 +0100, Anne van Kesteren
wrote:
* cross-origin request with preflight, actual request
If we want to follow redirects here at all we can only do it for
requests that do not require a preflight. Therefore I'm still not quite
convinced that we should honor 303 her
I took another look at redirects today.
* simple cross-origin request
For this case redirects can simply be followed. Some redirects will cause
the request method to be changed from HEAD, GET, or POST to GET. Per HTTP
that would be 303. Per implementations that would be 301, 302, and 303.
On 3/17/09, Frederick Hirsch wrote:
> Marcos
>
> Rather than replicating this, which might be error prone and hard to
> maintain, perhaps Widget Signature should reference P & C for this.
> What do you think ?
>
I think that should be fine.
> regards, Frederick
>
>
> On Mar 17, 2009, at 8:15 AM,
Marcos
Rather than replicating this, which might be error prone and hard to
maintain, perhaps Widget Signature should reference P & C for this.
What do you think ?
regards, Frederick
On Mar 17, 2009, at 8:15 AM, ext Marcos Caceres wrote:
Hi Frederick,
On 3/17/09 1:01 PM, Frederick Hir
Marcos, Frederick,
I should have asked Frederick to make the changes Marcos suggested
below. Sorry about that!
Anyhow, Frederick agreed to make the changes.
-Regards, Art Barstow
On Mar 17, 2009, at 8:44 AM, ext Marcos Caceres wrote:
On 3/17/09 12:59 PM, Frederick Hirsch wrote:
I alr
On Mon, 16 Mar 2009 11:12:01 -, Anne van Kesteren
wrote:
On Mon, 16 Mar 2009 12:07:22 +0100, Alexey Proskuryakov
wrote:
I think that the algorithm can only compare MIME types, not the full
Content-Type string.
I guess that makes sense.
I made this change now (defined in the "simple
On Mon, 16 Mar 2009 11:43:36 -, Alexey Proskuryakov
wrote:
Per the current CORS spec draft, cross-origin request with preflight
algorithm is followed if Content-Type is set, and it is not one of the
three predefined types. However, the preflight algorithm itself
immediately decides to
On Thu, Feb 26, 2009 at 6:34 PM, Thomas Roessler wrote:
> Marcos,
> R37 currently reads:
>
> A conforming specification MUST recommend that, at runtime, the addressing
> scheme used by a resource that addresses another resource within a widget
> package be resolved to some hierarchical URI scheme
On 3/17/09 12:59 PM, Frederick Hirsch wrote:
I already made this change :) to widget user agent. I think that should
work...
Sorry to be annoying, but we should be trying to architecturally design
all the specs to behave as independent as possible (and eradicate the
notion of an overall "
On Mon, Feb 23, 2009 at 3:31 PM, Scott Wilson
wrote:
> I agree that postponing any detailed work may be the most pragmatic answer,
> however oAuth is actually a very important technology for Widgets.
Agreed
> oAuth enables a user of an application such as a widget to link that
> application to a
On Fri, Mar 13, 2009 at 11:58 AM, Robin Berjon wrote:
> On Mar 13, 2009, at 08:33 , Thomas Landspurg wrote:
>>
>> Good suggestion. I think RSS/Atom is well adapted for new widgets
>> publication. I think that keeping the platform attribute is interesting,
>> because we - as many - we will have to
On Wed, 04 Mar 2009 11:00:43 +0100, Charles McCathieNevile
wrote:
> Hi folks,
>
> as a result of the great work by many, it seems we have all the things in
> place to move the Selectors API specification directly to Proposed
> Recommendation. In order to do so, we need to demonstrate that we hav
Hi Frederick,
On 3/17/09 1:01 PM, Frederick Hirsch wrote:
The latest draft includes the revised text from Thomas.
Marcos, are you suggesting we add something more? It sounds like what
you are saying here, is that it should be a valid widget file. Isn't
that part of P&C checking? I'm not sure w
I already made this change :) to widget user agent. I think that
should work...
On Mar 17, 2009, at 6:28 AM, ext Marcos Caceres wrote:
On Thu, Mar 12, 2009 at 5:53 PM, Priestley, Mark, VF-Group
wrote:
---
Editorial comments
---
General Te
The latest draft includes the revised text from Thomas.
Marcos, are you suggesting we add something more? It sounds like what
you are saying here, is that it should be a valid widget file. Isn't
that part of P&C checking? I'm not sure what it means to check that
the paths are "as secure as
On 3/17/09 12:40 PM, Arthur Barstow wrote:
Marcos,
On Mar 16, 2009, at 10:42 AM, ext Marcos Caceres wrote:
On Fri, Mar 13, 2009 at 2:22 PM, Frederick Hirsch
wrote:
Yes, I made this change since we decided this week to have case
sensitivity.
Too bad we have to use literals in hex for this c
Marcos,
On Mar 16, 2009, at 10:42 AM, ext Marcos Caceres wrote:
On Fri, Mar 13, 2009 at 2:22 PM, Frederick Hirsch
wrote:
Yes, I made this change since we decided this week to have case
sensitivity.
Too bad we have to use literals in hex for this case ...
Hmmm... is it bad that in the P&C
Hi Robin,
On Mon, Mar 16, 2009 at 5:03 PM, Robin Berjon wrote:
> Hi Marcos,
>
> On Mar 16, 2009, at 16:00 , Marcos Caceres wrote:
>>
>> On Mon, Mar 16, 2009 at 3:44 PM, Robin Berjon wrote:
>>>
>>> I would like to echo these concerns. I may have missed something but it
>>> is
>>> still rather uncl
On Mon, Mar 16, 2009 at 7:15 PM, wrote:
> I agree with Scott's concern.
>
> I'm not 100% up-to-speed with the latest modification to the HTML5 specs (if
> any) but I remember that this kind of "Rubyesque" way of accessing elements
> in the Storage is only present into the "attached usage examples
On Mon, Mar 16, 2009 at 6:33 PM, Scott Wilson
wrote:
> We've managed to implement Storage for Widget.preferences as an overlay over
> the older get/set method without any problems.
that's great to hear!
> One issue though is the HTML5 doc uses some syntax that relies on a
> Rubyesque method_miss
On Mon, Mar 16, 2009 at 12:17 PM, Thomas Roessler wrote:
> I'd suggest this instead:
>
>> Implementations should be careful about trusting path components found in
>> the zip archive: Such path components might be interpreted by operating
>> systems as pointing at security critical files outside
On Thu, Mar 12, 2009 at 6:27 PM, Marcin Hanclik
wrote:
> Hi Mark,
>
>>>"Implementations that store the content of widget archives to the file
>system during signature verification MUST NOT trust any path components of
>file names present in the archive, to avoid overwriting of arbitrary
On Thu, Mar 12, 2009 at 5:53 PM, Priestley, Mark, VF-Group
wrote:
> ---
> Editorial comments
> ---
>
> General Terminology
>
> "Widget agent", "widget platform", "application"? -> "widget user
> agent"?
Lets just use "user agent". I don't think we s
On Mon, 16 Mar 2009 12:49:15 +0100, Anne van Kesteren
wrote:
On Thu, 12 Mar 2009 15:28:51 +0100, Alexey Proskuryakov
wrote:
If the current text accurately describes how this flag is supposed to
work, I'd suggest an editorial change that will remove it, and say want
to pass to CORS directl
24 matches
Mail list logo
