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

[James M Snell <[e-mail]>]

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
  Host: example.org
  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: éxample.org

  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
Host: example.org

{.. 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
bit.

- James


On Thu, Apr 26, 2012 at 10:28 PM, Mark Nottingham <[e-mail]> wrote:
> Just a reminder that we're still accepting proposals for:
>
> 1. HTTP/2.0
> 2. New HTTP authentication schemes
>
> As per our charter <http://datatracker.ietf.org/wg/httpbis/charter/>.
>
> So far, we've received the following proposals applicable to HTTP/2.0:
>  <http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2Proposals>
>
> But none yet for authentication schemes:
>  <http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals>
>
> 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   http://www.mnot.net/
>
>
>
>