HTTP 2.0 (was Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard)

On Thu, Sep 24, 2009 at 10:52 AM, Julian Reschke <julian.reschke@gmx.de>wrote:

>
> These are orthogonal issues. You *could* define that there must be only one
> title. Also, HTTP can not easily be upgraded to change the header encoding;
> this has been discussed a lot over here in the last years, and my
> understanding is that we would need to change the major version number.
>

I'm increasingly often running into problems that could be relatively easily
fixed by upgrading the HTTP spec - after all we've been talking about HTTP
2.0 for 15 years<http://www.hpl.hp.com/personal/ange/archives/archives-95/http-wg-archive/0020.html>already
:P

The link header could already make a huge difference to the way the web
works (I've already started on this with
draft-johnston-addressing-link-relations<http://tools.ietf.org/html/draft-johnston-addressing-link-relations>),
but we're lacking the LINK and UNLINK verbs that HTTP originally defined for
managing them. Similarly, people often run into problems using PUT/POST for
requests that should have been handled by PATCH (which was also [poorly]
specified and then abandoned). Encodings are yet another issue I'm
increasingly coming up against for non-ASCII characters. "HTTP as a
meta-model" would also benefit from categories (which I have already
transplanted from Atom in
draft-johnston-http-category-header<http://tools.ietf.org/html/draft-johnston-http-category-header>).
Oh and let's not forget about pulling in the MOVE and COPY verbs from WebDAV
so we can instruct servers to migrate resources (e.g. push a VM from one
cloud to another).

I'd also like to have the ability to set persistent server-side "Cookies"
(or "Attributes" for a more appropriate term) using a similar process to
Set-Cookie, so much so that I'm considering writing an I-D specifying this.
The use case I have in mind is RESTful web services, specifically exposing
"attributes" of a virtual machine such as the number of cores, core speed,
memory size, etc. You can see an example below, where the OCCI-* headers
would be replaced by something like "Attribute: compute-cores=2" (which you
could update with an empty POST specifying Set-Attribute header(s) and
remove by including 'discard' ala Set-Cookie).

Another significant pain point for me (and apparently others) is
collections. URLs should be able to return multiple resources headers and
all, without having to resort to add-ons like multipart MIME. That way I
could ask for, say, all of the contacts in my mail account and have them
rendered as vCard but with metadata like author and security information,
web linking to other contacts (eg FOAF), web categories, etc. Presumably
this would be relatively easy to do by tweaking the spec (e.g. using CRLF
separators between resources) but today I'm having to use hacks like
text/uri-list which have O(n+1) rather than O(1) performance, or resorting
to formats like Atom for this special case.

There are of course plenty of other use cases, but the idea is to avoid
"wrapper" formats like Atom (which can add significant overhead in the form
of base64 encoding and/or O(n+1) requests, while neutering many HTTP
features such as range GETs and caching). The only other alternative for
metadata with opaque/non-hypertext resources is to create a distinct
content-type and/or resource which is clearly a hack when there is a
perfectly good existing out-of-band communication channel.

All in all I think that if we don't start to look at upgrading HTTP to
better cater for machine interfaces, advanced (semantic) clients and the
like then we're going to be bolting things like SOAP, Atom, RDF, etc. onto
it forever. It's looking increasingly like the OCCI Core
Protocol<http://occi.googlecode.com/hg/docs/occi-core.html>we're
working
on at OGF <http://www.occi-wg.org/> is basically a semantic version of HTTP
and some of these ideas could well be a starting point for HTTP 2.0 (in
which case I've been working in the wrong forum for this component of
OCCI!).

Sam

Retrieving a virtual machine using OCCI:

GET /myapp.ovf;web01 HTTP/1.1

Host: cloud.example.com


> HTTP 200 OK

Content-type: application/ovf

Content-length: 12345

OCCI-Hostname: myvm.cloud.example.com

OCCI-Compute-Cores: 2

OCCI-Compute-Speed: 3000

OCCI-Memory-Size: 2048

Link: </myvm.pdf>; rel="related"; type="application/pdf"; title="Build
> Documentation"

Link: </myvm.xen>; rel="alternative"; type="application/xen"; title="Xen
> Image"

Link: </myvm.ovf;action=stop>; rel="http://purl.org/occi/actions#stop";
> title="Stop"

Link: </myvm.ovf;action=restart>; rel="http://purl.org/occi/actions#restart";
> title="Restart"

Link: </myvm.png>; rel="http://purl.org/occi/relations/console#screenshot";
> title="Console Screenshot"

Link: <rdp://myvm.cloud.example.com>; rel="
> http://purl.org/occi/relations/console#rdp"; title="Remote Desktop
> Connection"

Link: <ssh://myvm.cloud.example.com>; rel="
> http://purl.org/occi/relations/console#ssh"; title="Secure SHell (SSH)"

Link: </networks/dmz>; rel="http://purl.org/occi/relations/network#interface";
> title="DMZ Interface"; address: 192.168.0.10/24; local="eth0";
> policy="allow tcp/80"

Link: </san/myvm>; rel="http://purl.org/occi/relations/storage#device";
> title="Root Device"; local="sda"

Category: windows; scheme="http://purl.org/occi/categories#operating-system";
> label="Windows"

Category: q123456; scheme="http://purl.org/occi/categories#microsoft-patches";
> label="Q123456 - Evil Bug"

Category: us-east; scheme="http://cloud.example.com/locations"; label="US
> East"

Category: staging; scheme="http://cloud.example.com/user-tags/";
> label="Staging"


> <?xml version="1.0" encoding="UTF-8" ?>

<!-- Open Virtualisation Format (OVF) -->