IETF Logo Mail Archive

Re: [OAUTH-WG] Proposal for text for section 2

Kris Selden <kris.selden@gmail.com> Wed, 30 June 2010 03:17 UTC

Return-Path: <kris.selden@gmail.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 0FA223A6801 for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 20:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level:
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
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 giv8iHspdq6F for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 20:17:50 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 37FFD3A63CA for <oauth@ietf.org>; Tue, 29 Jun 2010 20:17:50 -0700 (PDT)
Received: by pwj2 with SMTP id 2so98254pwj.31 for <oauth@ietf.org>; Tue, 29 Jun 2010 20:17:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=CaLbZRiPDWE3k6ez5oFFw/Twk+LydIYFpCaEgiANacE=; b=cLM6SogJo6oJAgjSGNRsrf9Fus3n7bTT163UaZ4fbrZFAU29izDbszv5CNbqtCxk8+ w3jbuA5duQDwbF7uiFa+iFFIEXUujNcT+L2WyqIR5P+YN0n2+8LzEDzywgGDtaB3b1du qlh2tNZtl8q9p96zGbTt1y5fdxBXd7xB0+S0A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=OEV6stQQOm1ljdbKH0MUf8QI8H+oakyQwLDhhSA68KQirSNHtR55kXxS+kB7fbwB0k Xc9Q0W2OjW83S1Wy+OsLon+lIT6qmj4OG0o70w6Jscv2CVm8RdfNoxQiqDnIcsnkqYBp 4U6X/uQnrYXLOJchUHetCDzoz/tqChKnw+RF4=
Received: by 10.115.64.21 with SMTP id r21mr8754935wak.23.1277867877990; Tue, 29 Jun 2010 20:17:57 -0700 (PDT)
Received: from [172.16.2.9] (c-76-121-106-185.hsd1.wa.comcast.net [76.121.106.185]) by mx.google.com with ESMTPS id c16sm5358679rvn.1.2010.06.29.20.17.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 29 Jun 2010 20:17:56 -0700 (PDT)
References: <7C01E631FF4B654FA1E783F1C0265F8C579CC0C3@TK5EX14MBXC117.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C579D0F31@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11265A5FC9D@WSMSG3153V.srv.dir.telstra.com> <AANLkTilrSUMEjsF-3RHuit6aoAPRe0DAqR6Uz2ldrd_l@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E11265B7E474@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BF7C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BF7C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Mime-Version: 1.0 (iPhone Mail 8A293)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"
Message-Id: <4AB71D81-6285-46D6-9D4A-99966616E0F1@gmail.com>
X-Mailer: iPhone Mail (8A293)
From: Kris Selden <kris.selden@gmail.com>
Date: Tue, 29 Jun 2010 20:17:58 -0700
To: Eran Hammer-Lahav <eran@hueniverse.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Proposal for text for section 2
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: Wed, 30 Jun 2010 03:17:51 -0000

This is configurable in IIS, Apache and Nginx but the default ranges from 4k to 16k.

Don't know if there are issues with buffer sizes on the client side.

On Jun 29, 2010, at 5:14 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

> More precisely, what are the actual deployed limits on HTTP *request* headers in popular HTTP servers like Apache and IIS, and in popular client platform likely to use this size assertions?
> 
> EHL
> 
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Manger, James H
>> Sent: Tuesday, June 29, 2010 5:08 PM
>> To: Marius Scurtescu
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Proposal for text for section 2
>> 
>> Marius,
>> 
>>>> For instance, why not define a SAML HTTP authentication mechanism:
>>>> 
>>>>    Authorization: SAML a=<base64url-encoded SAML assertion>
>> 
>>> This came up in another thread, but SAML assertions could be too large
>>> to be passed through an HTTP header. Other than that, your suggestion
>>> really simplifies things.
>> 
>> What are the limits on HTTP headers?
>> I don't think there are any in the HTTP spec.
>> <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-09#section-3.2>
>> A comment in the other thread said SPNEGO headers can be up to 12392
>> bytes and do not seem to be a problem.
>> <http://www.ietf.org/mail-archive/web/oauth/current/msg03359.html>
>> 
>> I is hard to support a POST-and-form-only method when there is an
>> alternative that "really simplifies things" without more concrete information
>> on what the actual HTTP limits are (& how hard it is to increase them), and
>> what practical assertion sizes are.
>> 
>> 
>> --
>> James Manger
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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