Re: Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication

James M Snell <> Fri, 27 April 2012 06:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF56521F8740 for <>; Thu, 26 Apr 2012 23:54:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s9G0rMaSzCTH for <>; Thu, 26 Apr 2012 23:54:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8459E21F86FA for <>; Thu, 26 Apr 2012 23:54:25 -0700 (PDT)
Received: from lists by with local (Exim 4.69) (envelope-from <>) id 1SNf29-00086Y-N4 for; Fri, 27 Apr 2012 06:52:01 +0000
Received: from ([]) by with esmtp (Exim 4.69) (envelope-from <>) id 1SNeuF-0004f9-Mz for; Fri, 27 Apr 2012 06:43:51 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1SNeuC-0003i1-1e for; Fri, 27 Apr 2012 06:43:49 +0000
Received: by wibhn6 with SMTP id hn6so229783wib.8 for <>; Thu, 26 Apr 2012 23:43:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=qIfsPe0QnPsgJH3gTCi448Y434tJStK7r0Fq5ywTJpE=; b=Eu/T5TiWe7flmpKPOVrfvmpVLGjoeeNljcpJe4HMDn/b4T/CMb2Tg7rnQM63rZjnN2 6A0LdzP7DiJdKUoRwddSqrlpSsJ5eMgnux3GxSfoLYrbaPco3N3+dKuY2MwuRKsD2PaX 3187fG1OkZMRzdR1hbWHfh15Vype1cj7DoooilVgKp1umAzXcph3AqOUSQ32yT30Xs8a 6LB6Y2swzOs9d9AKFdAkfHyMpuPP9kMaUcqRfvXdg6ZhruIVTtLcKPUo+am4VR5u6o6E P/othiybn2R7lGumREXaT23cqqnrRzmCsI8kcGyE1p2vHwRLDek3PlaNLRjJOnB/P4La Q6Aw==
Received: by with SMTP id cf8mr2974453wib.0.1335509002101; Thu, 26 Apr 2012 23:43:22 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 26 Apr 2012 23:43:01 -0700 (PDT)
In-Reply-To: <>
References: <>
From: James M Snell <>
Date: Thu, 26 Apr 2012 23:43:01 -0700
Message-ID: <>
To: Mark Nottingham <>
Cc: HTTP Working Group <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-2.7
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1SNeuC-0003i1-1e be50e80f172aa57273dc0fec208c84e0
Subject: Re: Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication
Archived-At: <>
X-Mailing-List: <> archive/latest/13481
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>
Resent-Message-Id: <>
Resent-Date: Fri, 27 Apr 2012 06:52:01 +0000

Great to see this work getting underway. I don't have any particular
firm proposals from a fundamental HTTP/2.0 messaging and semantics
level, but I do have a few items on my wishlist from an HTTP-based API
developers point of view that I would like to see addressed in 2.0..

Requirements to Consider for HTTP/2.0 from an API Developers Point of View

1. It needs to remain as simple as possible. Right now, when showing
someone how to utilize an API, I can simply type:

  POST /a/uri HTTP/1.1
  Content-Type: text/plain

  Hello World

  And give them all the information they need. Whatever the actual
transport ends up being, at some level we have to make sure we don't
lose this kind of "View Source" visibility.

2. Allow the Request-URI to be a Request-IRI so no conversion is
necessary. E.g. it should be possible to do this at the request level
and have it just work...

  POST /a/üri HTTP/2.0
  Host: é

  For that matter, can we allow extended characters in all the headers
and use UTF-8 as the default encoding.

3. Use ISO-8601/RFC3339 Timestamps for more precise date/time handling

  Date: 2012-12-12T12:12:12Z
  Last-Modified: 2012-12-12T12:12:12.012Z
  Expires: 2012-12-12T12:12:12.123Z
  // or even

  Expires: P2D3H    (using an ISO-8601 Duration)

4. It would be helpful to have a "standard" means of signing requests
and responses. SSL/TLS is good, but it doesn't always meet the
requirement (see OpenSocial Signed Fetch as an example)

5. Batched-Requests keep popping up and implementors keep coming up
with proprietary ways of handling them (e.g. Facebook, Google,
OpenSocial.. and others). The primary reason given is efficiency...
doing more stuff in a single request. It would be helpful for HTTP/2.0
to definitively address this so we don't keep ending up with a bunch
of relatively half-baked vendor specific batching models that attempt
to bundle http message semantics inside message payloads.

6. Please consider incorporating the Mac and Bearer token
authentication mechanisms as standard HTTP authentication schemes.

7. Please consider incorporating the PATCH method into the core set of
HTTP 2.0 Methods

8. Please consider incorporating the Prefer header into the core set
of HTTP 2.0 request headers.

9. The X-HTTP-Method-Override header has emerged as the de facto
standard way of getting around intermediaries that inadvertently block
extension http methods (like PATCH). It would be helpful for HTTP/2.0
to offer some prescriptive solution so that this kind of
Tunneling-through-POST hack isn't necessary any more.

10. Currently within HTTP/1.1 the 202 Accepted response says The
representation returned with this response SHOULD include an
indication of the request's current status and either a pointer to a
status monitor or some estimate of when the user can expect the
request to be fulfilled" but otherwise does not provide a standardized
means of referencing the location of the status monitor or determining
whether the asynchronous operation is complete. A variety of means
have been proposed but it would be helpful for 2.0 to flesh this out
in detail. For instance, a Location header in the 202 response can be
used to reference the status monitor; when a user-agent then does a
GET on that URL, a 202 response can indicate that the request is still
being processed. e.g.

// post a long running request //
POST /some/resource HTTP/2.0

{.. some data to process ..}

// get back an asynchronous response //
HTTP/2.0 202 Accepted
Location: http://.../status-monitor/1
Retry-After: 120

// check the status 120 seconds later //
GET /status-monitor/1 HTTP/2.0
Host: ...

// response is not yet completed
HTTP/2.0 202 Accepted
Location: http://.../status-monitor/1
Retry-After: 120

// check the status 120 seconds later //
GET /status-monitor/1 HTTP/2.0
Host: ...

// processing is complete, server returns a redirect to the actual resource
HTTP/2.0 302 Found
Location: http://.../the/resource

The use of the 2xx status code rather than 3xx avoids the potential
for an endless redirect loop with user-agents that blinding follow
unknown/unrecognized redirection codes. Also, if you consider the
nature of the status monitor, a notice to the client that the
processing is not yet complete is a valid success response.

Specifying this kind of behavior out in detail will allow asynchronous
operations to be deployed in an interoperable and reliable way.

In any case, that's all I have for now. I'm sure other ideas will pop
into mind later on but hopefully these are enough to chew on for a

- James

On Thu, Apr 26, 2012 at 10:28 PM, Mark Nottingham <> wrote:
> Just a reminder that we're still accepting proposals for:
> 1. HTTP/2.0
> 2. New HTTP authentication schemes
> As per our charter <>.
> So far, we've received the following proposals applicable to HTTP/2.0:
>  <>
> But none yet for authentication schemes:
>  <>
> As communicated in Paris, the deadline for proposals is 15 June, 2012. It's fine if your proposal isn't complete, but we do need to have a  good sense of it by then, for discussion.
> Regards,
> --
> Mark Nottingham