[OAUTH-WG] HTTP/1.0 and JSON

Tim Brody <tdb2@ecs.soton.ac.uk> Wed, 15 June 2011 12:41 UTC

Return-Path: <tdb2@ecs.soton.ac.uk>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A6621F84FE for <oauth@ietfa.amsl.com>; Wed, 15 Jun 2011 05:41:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXNSOaZPWGW2 for <oauth@ietfa.amsl.com>; Wed, 15 Jun 2011 05:41:51 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0A221F84FC for <oauth@ietf.org>; Wed, 15 Jun 2011 05:41:51 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5FCfn8v023933 for <oauth@ietf.org>; Wed, 15 Jun 2011 13:41:49 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p5FCfn8v023933
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1308141709; bh=Mx+6m7bRWjJQAU+Lh2oYOkeRxc8=; h=Subject:From:To:Date:Mime-Version:References; b=RYGLIpJ+G3UsIUcghFC7eAMQF0uhIvhp9rnmsbONuSmq3t9D4OVQMytUMSwQ9OOMB AMUNFQlBEEZO6ygLf1T6HA8ioxMOgmmVMBW0nuWS+r4F90DYKHh+TPoJzdZIJ56SS0 ClDJthzcng/Et9c/1AZkQN9oSZoNGBtv0uJNSlHQ=
Received: from imap.ecs.soton.ac.uk (imap.ecs.soton.ac.uk [2001:630:d0:f102:21e:c9ff:fee7:83c0]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from <tdb2@ecs.soton.ac.uk> with ESMTP id n5EDfn0521312074Z6 ret-id none; Wed, 15 Jun 2011 13:41:49 +0100
Received: from [IPv6:2001:630:d0:f111:230:48ff:fed6:4e94] ([IPv6:2001:630:d0:f111:230:48ff:fed6:4e94]) (authenticated bits=0) by imap.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5FCfh3I030073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <oauth@ietf.org>; Wed, 15 Jun 2011 13:41:44 +0100
From: Tim Brody <tdb2@ecs.soton.ac.uk>
To: oauth@ietf.org
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 15 Jun 2011 13:41:43 +0100
Message-ID: <EMEW3|2d472212bace21e440b5fb833192f747n5EDfn04tdb2|ecs.soton.ac.uk|1308141703.2268.211.camel@chassis.ecs.soton.ac.uk>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Content-Transfer-Encoding: 7bit
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=n5EDfn052131207400; tid=n5EDfn0521312074Z6; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
References: <1308141703.2268.211.camel@chassis.ecs.soton.ac.uk>
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: p5FCfn8v023933
X-ECS-MailScanner-From: tdb2@ecs.soton.ac.uk
Subject: [OAUTH-WG] HTTP/1.0 and JSON
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 15 Jun 2011 12:41:52 -0000

Hi All,

I'm the author of this Perl library for signing OAuth 1.0 requests:
http://search.cpan.org/~timbrody/LWP-Authen-OAuth-1.01/

I've been asked about OAuth 2.0 so have scanned through the spec and
joined this list :-)


The MAC-signing draft section 1.2 refers to "Host:" but I have an HTTP
library that can talk 1.0 or 1.1. I make an HTTP request with URI + form
parameters + extra headers - I don't know if the "Host:" header will
exist. So, can you just refer to the "hostname" and "port"? (Whether
they are in the URI or a Host: header seems orthogonal to OAuth anyway?)


Why do you POST application/x-www-form-urlencoded but get
application/json?

I couldn't find a conclusion to the May 2010 discussions about using
x-www-form-urlencoded vs. json nor a rationale in the spec for using
JSON. Why do I need to add a JSON lexer/parser to my library just to get
key-value pairs that can be represented by form-urlencoded?


All the best,
Tim.