HTTP 2.0 (was Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard)
Sam Johnston <samj@samj.net> Fri, 25 September 2009 11:32 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296413A6A2F for <ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com>; Fri, 25 Sep 2009 04:32:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.934
X-Spam-Level:
X-Spam-Status: No, score=-6.934 tagged_above=-999 required=5 tests=[AWL=-0.803, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_BACKHAIR_57=1, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_HI=-8]
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 U61rhG91uInc for <ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com>; Fri, 25 Sep 2009 04:32:35 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 396FF3A6A21 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 25 Sep 2009 04:32:35 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Mr931-00035Y-Ve for ietf-http-wg-dist@listhub.w3.org; Fri, 25 Sep 2009 11:33:12 +0000
Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from <samj@samj.net>) id 1Mr92u-00034v-TF for ietf-http-wg@listhub.w3.org; Fri, 25 Sep 2009 11:33:04 +0000
Received: from eu1sys200aog110.obsmtp.com ([207.126.144.129]) by bart.w3.org with smtp (Exim 4.69) (envelope-from <samj@samj.net>) id 1Mr92k-000393-OV for ietf-http-wg@w3.org; Fri, 25 Sep 2009 11:33:04 +0000
Received: from source ([209.85.218.217]) by eu1sys200aob110.postini.com ([207.126.147.11]) with SMTP ID DSNKSryqSslYRxzeiazSpAfEk2zctOmT2okA@postini.com; Fri, 25 Sep 2009 11:32:54 UTC
Received: by bwz17 with SMTP id 17so1901457bwz.45 for <ietf-http-wg@w3.org>; Fri, 25 Sep 2009 04:32:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.239.142.155 with SMTP id g27mr3296hba.62.1253878345777; Fri, 25 Sep 2009 04:32:25 -0700 (PDT)
Date: Fri, 25 Sep 2009 12:32:25 +0100
Message-ID: <21606dcf0909250432q7026616du456ed594aeb0aafa@mail.gmail.com>
From: Sam Johnston <samj@samj.net>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Ian Hickson <ian@hixie.ch>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: multipart/alternative; boundary="001485f2774e64430a0474654d2f"
Received-SPF: pass
X-SPF-Guess: pass
X-W3C-Hub-Spam-Status: No, score=-1.7
X-W3C-Hub-Spam-Report: BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: bart.w3.org 1Mr92k-000393-OV 4738d761749613f34fd21f200b2bee7f
X-Original-To: ietf-http-wg@w3.org
Subject: HTTP 2.0 (was Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard)
Archived-At: <http://www.w3.org/mid/21606dcf0909250432q7026616du456ed594aeb0aafa@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/7765
X-Loop: ietf-http-wg@w3.org
Sender: ietf-http-wg-request@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1Mr931-00035Y-Ve@frink.w3.org>
Resent-Date: Fri, 25 Sep 2009 11:33:11 +0000
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) -->
- HTTP 2.0 (was Re: Last Call: draft-nottingham-htt… Sam Johnston
- Re: HTTP 2.0 (was Re: Last Call: draft-nottingham… Julian Reschke