Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON

Eran Hammer-Lahav <eran@hueniverse.com> Mon, 19 April 2010 05:13 UTC

Return-Path: <eran@hueniverse.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 4CB2A3A6907 for <oauth@core3.amsl.com>; Sun, 18 Apr 2010 22:13:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.469
X-Spam-Level:
X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599]
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 BmkB+6och4O4 for <oauth@core3.amsl.com>; Sun, 18 Apr 2010 22:13:08 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E11AE3A6895 for <oauth@ietf.org>; Sun, 18 Apr 2010 22:13:07 -0700 (PDT)
Received: (qmail 17624 invoked from network); 19 Apr 2010 05:12:59 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Apr 2010 05:12:59 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 18 Apr 2010 22:13:00 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Dick Hardt <dick.hardt@gmail.com>, OAuth WG <oauth@ietf.org>
Date: Sun, 18 Apr 2010 22:13:01 -0700
Thread-Topic: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
Thread-Index: AcrfeQljil97mhwYS/681iScbr8TggABRLvw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723438E30A379B@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com>
In-Reply-To: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
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: Mon, 19 Apr 2010 05:13:10 -0000

Every format requires some encoding, and if we limit the character set we will just be pushing the problem elsewhere (forcing servers to encode or define encoding for clients). Right now the assumption is that developers will implement the format (form-encoded) correctly, which will take care of any unexpected value. We can be more explicit about warning them no to assume anything about the values they receive.

Interop requires that servers always use the format defined by the spec, but may offer more formats per client request. This requires an extension parameter or a preference in the client configuration.

I don't have a preference between JSON and form-encoded, but will point out that form-encoded is MUCH easier to parse without a library than JSON or XML. We can also offer both and define a client request parameter (as long as the server is required to make at least one format available).

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Dick Hardt
> Sent: Sunday, April 18, 2010 9:30 PM
> To: OAuth WG
> Subject: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
> 
> The AS token endpoint response is encoded as application/x-www-form-
> urlencoded
> 
> While this reuses a well known and understood encoding standard, it is
> uncommon for a client to receive a message encoded like this. Most server
> responses are encoded as XML or JSON. Libraries are NOT reedily available to
> parse application/x-www-form-urlencoded results as this is something that is
> typically done in the web servers framework. While parsing the name value
> pairs and URL un-encoding them is not hard, many developers have been
> caught just splitting the parameters and forgetting to URL decode the token.
> Since the token is opaque and may contain characters that are escaped, it is a
> difficult bug to detect.
> 
> Potential options:
> 
> 1) Do nothing, developers should read the specs and do the right thing.
> 
> 2) Require that all parameters are URL safe so that there is no encoding issue.
> 
> 3) Return results as JSON, and recommend that parameters be URL safe.
> 
> -- Dick
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth