I believe Flash (in the browser) has similar constraints. Don't know
about Silverlight.
Thanks,
George
On 8/17/10 10:33 PM, John Panzer wrote:
Is there any legit reason other than jsonp specifically?
In the wild I mean.
On Tuesday, August 17, 2010, Brian Eaton<bea...@google.com> wrote:
On Tue, Aug 17, 2010 at 11:48 AM, David Recordon<record...@gmail.com> wrote:
Luke's point still holds true of the core spec needing to allow a 200 status
code on an error in this scenario. I'd also rather see this as part of the
core spec as it reduces the number of things that implementors will need to
read for common use cases.
For the record, I think any implementer that is relying on protected
resources returning special response codes for any type of OAuth
protocol issue is probably going to get burned. Variation in
protected resource behavior has been a consistent problem in OAuth
1.0, and I doubt that can change in OAuth 2.
It's tough to get protected resource servers to be consistent; they
frequently have good reasons (e.g. jsonp) to be inconsistent.
Authorization servers are simpler beasts.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
