IETF Logo Mail Archive

Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP

George Fletcher <gffletch@aol.com> Fri, 20 August 2010 13:09 UTC

Return-Path: <gffletch@aol.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E531B3A6768 for <oauth@core3.amsl.com>; Fri, 20 Aug 2010 06:09:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.669
X-Spam-Level:
X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzmV+0z1fjLG for <oauth@core3.amsl.com>; Fri, 20 Aug 2010 06:09:20 -0700 (PDT)
Received: from imr-db01.mx.aol.com (imr-db01.mx.aol.com [205.188.91.95]) by core3.amsl.com (Postfix) with ESMTP id 193E13A68F1 for <oauth@ietf.org>; Fri, 20 Aug 2010 06:09:19 -0700 (PDT)
Received: from mtaout-ma02.r1000.mx.aol.com (mtaout-ma02.r1000.mx.aol.com [172.29.41.2]) by imr-db01.mx.aol.com (8.14.1/8.14.1) with ESMTP id o7KD9XEL021927; Fri, 20 Aug 2010 09:09:33 -0400
Received: from palantir.local (unknown [10.172.0.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma02.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id E257CE000098; Fri, 20 Aug 2010 09:09:32 -0400 (EDT)
Message-ID: <4C6E7E8A.3010107@aol.com>
Date: Fri, 20 Aug 2010 09:09:30 -0400
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: John Panzer <jpanzer@google.com>
References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <D2742806-9180-4A5B-98D5-BFD68AF74EEA@facebook.com> <AANLkTikvz1FNvHN0W4TYyUn=0Nq_At2c+x793XTdwyLm@mail.gmail.com> <AANLkTinBqMvmKuoUq7Fy7XmJue5VEFYcw7qoca=0cWFs@mail.gmail.com> <4C69B719.3060303@lodderstedt.net> <DFB12E92-0E4D-46C2-8103-C74BAE6F65F9@facebook.com> <4C6A25F7.8060301@lodderstedt.net> <AANLkTinHehcMCsmxJt0hvLbLrLC5ERrjG38GDxaAMsiZ@mail.gmail.com> <241FE353-C52A-4505-8620-DEE9CF9F940E@lodderstedt.net> <FC1E2149-F8FF-4010-AAB8-273F8E2DC498@facebook.com> <AANLkTinz4r3AwTva1fu0okobC70Ht1gZei5wjN2eQW3H@mail.gmail.com> <AANLkTinSCrXs1LaLY1ByNFi_Ec9WOr2ETQdpRXYfm+ra@mail.gmail.com> <AANLkTinriRSq9_z4M-Brr59pyhJQm8aGaMnh6dsmmjqH@mail.gmail.com> <AANLkTi=vGVVzzaQ8AP+bN=YU6_EXavc_M9Xr-sFLvL76@mail.gmail.com>
In-Reply-To: <AANLkTi=vGVVzzaQ8AP+bN=YU6_EXavc_M9Xr-sFLvL76@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------010508080205000208070606"
x-aol-global-disposition: G
X-AOL-SCOLL-SCORE: 0:2:467328128:93952408
X-AOL-SCOLL-URL_COUNT: 0
x-aol-sid: 3039ac1d29024c6e7e8c02c1
X-AOL-IP: 10.172.0.205
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Aug 2010 13:09:27 -0000

  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<beaton@google.com>  wrote:
>> On Tue, Aug 17, 2010 at 11:48 AM, David Recordon<recordond@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.
>>

v2.30.2 | Report a Bug | By Email | System Status