Re: [cors] 27 July 2010 CORS feedback

On Tue, Nov 23, 2010 at 7:36 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> * Jonas Sicking wrote:
>>other person: Hmm.. we might want to disable cross-site posting for
>>forms some day, so is it such a good idea that cors enables it?
>>me: If we do disable it for forms we'll just disable it for cors too.
>>So much content will break for forms that the cors breakage won't be
>>what we're concerned about.
>>other person: Yeah, true.
>
> At the point where browser vendors actually disable cross site form
> posts it won't break a lot of sites, since browser vendors are not in
> the habit of making changes that break a lot of sites.

This sounds like a very hypothetical world.

> At best we'd
> have a vendor like Microsoft less concerned with having only one code
> path for everything who'd disable them in certain modes or based on
> certain headers or something like that, so they will slowly be phased
> out, alongside efforts to change major sites and educating developers.

This is a very strange statement. We have lots of code paths in gecko
where we take different code paths based on header values. In fact,
that's how every single header is implemented.

But even if it is true, why wouldn't those headers affect CORS POSTs
the same way they they limit <form> POSTs?

> If not doing cross site posts without authorization is a goal, teaching
> authors it's fine to make cross site posts without authorization
> undermines that goal. It means more work for everyone to get to a point
> where browser vendors would even have this discussion. What you are
> saying amounts to telling authors "Hey, here is a new way to do cross
> site posts; btw, if you use this, we are planning on breaking your site
> and thousands of others." That's not very reasonable.

How is CORS teaching authors that cross-site POSTs are ok any more
than HTML is? HTML also defines that cross-site POSTs should work.

/ Jonas

Received on Wednesday, 24 November 2010 05:07:52 UTC