Re: [cors] Simplify CORS Headers (ISSUE-89)

[Anne van Kesteren]

On Fri, 07 May 2010 02:30:10 +0200, Anne van Kesteren   
wrote:
Here is a brief proposal for how we could simplify the current set of  
CORS headers. We can use this thread to evaluate whether it is worth  
breaking with what Firefox, Safari, Chrome, and IE are doing now. And  
whether all parties are willing to change their supported syntax in due  
course.


Furthermore, I suggest that if we have nothing conclusive on this topic  
by June 15 we consider ISSUE-89[1] as resolved. We have to move on at  
some point. (Maybe the chairs should issue a CfC for this to make it  
official.)


It seems we have actually something conclusive by today. Namely that we  
are not interested as a WG in renaming the headers of CORS. I will close  
the issue.




[1]



--
Anne van Kesteren
http://annevankesteren.nl/

RE: [cors] Simplify CORS Headers (ISSUE-89)

[Adrian Bateman]

On Wednesday, May 26, 2010 1:05 PM, Adam Barth wrote:
> On Wed, May 26, 2010 at 9:08 AM, Tyler Close  wrote:
> > On Mon, May 24, 2010 at 8:23 AM, Adrian Bateman 
> wrote:
> > > In IE, we only support Access-Control-Allow-Origin and combining with
> > >other values (albeit optional ones) that we don't support might be
> > >misleading. It also introduces some additional parsing that changes the
> > >behaviour from a simple comparison to a more complex parse and then 
> > >compare.
> >
> > The above statement seems to imply that there are no plans for IE to
> > support the optional features of CORS such as pre-flight and user
> > credentials. Am I reading the statement correctly?
> 
> I don't mean to speak for Adrian, but Microsoft doesn't usually
> comment on future product releases.  I suspect that's because of
> various legal requirements in the US regarding forward-looking
> statements.

Thanks Adam. To be clear, we currently don't support pre-flight/user 
credentials and we have not announced any plans to do so. I can't comment on 
what we might do in a future release.

Thanks,

Adrian.

Re: [cors] Simplify CORS Headers (ISSUE-89)

[Adam Barth]

On Wed, May 26, 2010 at 9:08 AM, Tyler Close  wrote:
> On Mon, May 24, 2010 at 8:23 AM, Adrian Bateman  
> wrote:
>> In IE, we only support Access-Control-Allow-Origin and combining with other 
>> values (albeit optional ones) that we don't support might be misleading. It 
>> also introduces some additional parsing that changes the behaviour from a 
>> simple comparison to a more complex parse and then compare.
>
> The above statement seems to imply that there are no plans for IE to
> support the optional features of CORS such as pre-flight and user
> credentials. Am I reading the statement correctly?

I don't mean to speak for Adrian, but Microsoft doesn't usually
comment on future product releases.  I suspect that's because of
various legal requirements in the US regarding forward-looking
statements.

Kind regards,
Adam

Re: [cors] Simplify CORS Headers (ISSUE-89)

[Tyler Close]

On Mon, May 24, 2010 at 8:23 AM, Adrian Bateman  wrote:
> In IE, we only support Access-Control-Allow-Origin and combining with other 
> values (albeit optional ones) that we don't support might be misleading. It 
> also introduces some additional parsing that changes the behaviour from a 
> simple comparison to a more complex parse and then compare.

The above statement seems to imply that there are no plans for IE to
support the optional features of CORS such as pre-flight and user
credentials. Am I reading the statement correctly?

Thanks,
--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

RE: [cors] Simplify CORS Headers (ISSUE-89)

[Adrian Bateman]

In IE, we only support Access-Control-Allow-Origin and combining with other 
values (albeit optional ones) that we don't support might be misleading. It 
also introduces some additional parsing that changes the behaviour from a 
simple comparison to a more complex parse and then compare.

We wouldn't be able to drop support for the current header so we'd need to 
support both and have a precedence order for which wins if both headers are 
present with different values. It's unlikely we'd issue a patch for IE8 unless 
there was strong customer demand and even if we did, there's no guarantee that 
it would be installed so services would still need to send both headers.

I'm not all that keen on changing the names at this point either.

Adrian.

On Friday, May 14, 2010 10:19 AM, Arthur Barstow wrote:
> Simpler and/or shorter would indeed be good, although it may be too
> late.
> 
> Jonas, IE Guys (Chris, Adrian, ...) - what is your input on this issue?
> 
> -Art Barstow
> 
> On May 13, 2010, at 3:39 AM, ext Maciej Stachowiak wrote:
> > On May 6, 2010, at 5:30 PM, Anne van Kesteren wrote:
> >> I suggest we merge Access-Control-Allow-Origin, Access-Control-
> >> Allow-Credentials, and Access-Control-Max-Age into a new header,
> >> named CORS. The syntax of this new header would be:
> >>
> >>  "CORS" : "credentials"? origin-value delta-seconds?

> > I'm not that keen on changing the names, but if we do, I think
> > "CORS" might be a bit mysterious by itself as a header name. Here's
> > another set of naming suggestions, if we do go down the renaming
> > path (which for the record I'd rather not):
> >
> > CORS ==> Allow-Access or Expose-Response
> > CORS-Methods ==> Allow-Methods
> > CORS-Headers ==> Allow-Headers (or Allow-Request-Headers)
> > CORS-Preflight ==> can't think of a better name for this
> > new header to expose more response headers ==> Expose-Headers (or
> > Expose-Response-Headers)
> >
> > Regards,
> > Maciej
> 

Re: [cors] Simplify CORS Headers (ISSUE-89)

[Jonas Sicking]

On Fri, May 14, 2010 at 10:18 AM, Arthur Barstow  wrote:
> Simpler and/or shorter would indeed be good, although it may be too late.
>
> Jonas, IE Guys (Chris, Adrian, ...) - what is your input on this issue?

Like I've said before, I'd be fine with transitioning to new header
names, but it'd require consensus from IE and Webkit too.

/ Jonas

Re: [cors] Simplify CORS Headers (ISSUE-89)

[Arthur Barstow]

Simpler and/or shorter would indeed be good, although it may be too  
late.


Jonas, IE Guys (Chris, Adrian, ...) - what is your input on this issue?

-Art Barstow

On May 13, 2010, at 3:39 AM, ext Maciej Stachowiak wrote:



On May 6, 2010, at 5:30 PM, Anne van Kesteren wrote:

Here is a brief proposal for how we could simplify the current set  
of CORS headers. We can use this thread to evaluate whether it is  
worth breaking with what Firefox, Safari, Chrome, and IE are doing  
now. And whether all parties are willing to change their supported  
syntax in due course.


Furthermore, I suggest that if we have nothing conclusive on this  
topic by June 15 we consider ISSUE-89[1] as resolved. We have to  
move on at some point. (Maybe the chairs should issue a CfC for  
this to make it official.)



I suggest we merge Access-Control-Allow-Origin, Access-Control- 
Allow-Credentials, and Access-Control-Max-Age into a new header,  
named CORS. The syntax of this new header would be:


 "CORS" : "credentials"? origin-value delta-seconds?

Access-Control-Allow-Methods and Access-Control-Allow-Headers  
become CORS-Methods and CORS-Headers respectively. I do not think  
it is worth trying to merge these in as well.


We keep the Origin header.

And Access-Control-Request-Method and Access-Control-Request- 
Headers are merged into a new header, named CORS-Preflight. The  
syntax of this new header would be:


 "CORS-Preflight" : Method [SP field-name]*


[1]




I'm not that keen on changing the names, but if we do, I think  
"CORS" might be a bit mysterious by itself as a header name. Here's  
another set of naming suggestions, if we do go down the renaming  
path (which for the record I'd rather not):


CORS ==> Allow-Access or Expose-Response
CORS-Methods ==> Allow-Methods
CORS-Headers ==> Allow-Headers (or Allow-Request-Headers)
CORS-Preflight ==> can't think of a better name for this
new header to expose more response headers ==> Expose-Headers (or  
Expose-Response-Headers)


Regards,
Maciej

Re: [cors] Simplify CORS Headers (ISSUE-89)

[Maciej Stachowiak]

On May 6, 2010, at 5:30 PM, Anne van Kesteren wrote:

> Here is a brief proposal for how we could simplify the current set of CORS 
> headers. We can use this thread to evaluate whether it is worth breaking with 
> what Firefox, Safari, Chrome, and IE are doing now. And whether all parties 
> are willing to change their supported syntax in due course.
> 
> Furthermore, I suggest that if we have nothing conclusive on this topic by 
> June 15 we consider ISSUE-89[1] as resolved. We have to move on at some 
> point. (Maybe the chairs should issue a CfC for this to make it official.)
> 
> 
> I suggest we merge Access-Control-Allow-Origin, 
> Access-Control-Allow-Credentials, and Access-Control-Max-Age into a new 
> header, named CORS. The syntax of this new header would be:
> 
>  "CORS" : "credentials"? origin-value delta-seconds?
> 
> Access-Control-Allow-Methods and Access-Control-Allow-Headers become 
> CORS-Methods and CORS-Headers respectively. I do not think it is worth trying 
> to merge these in as well.
> 
> We keep the Origin header.
> 
> And Access-Control-Request-Method and Access-Control-Request-Headers are 
> merged into a new header, named CORS-Preflight. The syntax of this new header 
> would be:
> 
>  "CORS-Preflight" : Method [SP field-name]*
> 
> 
> [1]
> 


I'm not that keen on changing the names, but if we do, I think "CORS" might be 
a bit mysterious by itself as a header name. Here's another set of naming 
suggestions, if we do go down the renaming path (which for the record I'd 
rather not):

CORS ==> Allow-Access or Expose-Response
CORS-Methods ==> Allow-Methods
CORS-Headers ==> Allow-Headers (or Allow-Request-Headers)
CORS-Preflight ==> can't think of a better name for this
new header to expose more response headers ==> Expose-Headers (or 
Expose-Response-Headers)

Regards,
Maciej