HTTP 0.2 (ie., HTTP 2.0 / 10)

Less is really more.

A minimalist and sane subset of HTTP that maps well to 9P and encompasses the best RESTful practices.

Goals

While being simpler than HTTP 1.1 by ignoring all the unused and clunky bits, define conventions that would allow us to replace most of the functionality of:

WebDAV
AtomPub

Should be possible to implement a server using existing frameworks, eg., CGI. Writing new implementations from scratch should be trivial without depending on any external library.

Backwards compatibility:

Clients should generate requests that all HTTP 1.1 servers can understand (aside from conventions for directory listing, file creation, etc.)
Servers should generate replies that all HTTP 1.1 clients can understand.

Sub-standards (pun intended ;))

Parts of the HTTP 0.2 standard:

A simple and sane subset of the URI spec.
A small subset of the HTTP 1.1 headers and methods (GET and POST only?)
A convention on the semantics of actions on directories, to allow file creation/listing/deletion and metadata related operations without using PUT/DEL or any other ‘esoteric’ HTTP ‘features’.
A simplified BNF grammar with sane syntax for things like header.

Pre-existing components we can reuse

UTF-8 everywhere we can.
JSON, might be a good format for representing file metadata and even file manipulation operation commands, perhaps.

Things we should try to avoid

We should only define new headers if no alternative is possible.

Things we must kill (if we can)

This is a wishlist of horribly complex and mostly useless HTTP ‘features’ that should die:

Cookies.
Query strings.
Pipelining.
Lots of other crud.

Open questions

How to handle auth?
Non TCP transports. STCP?
Should we define a strict mapping to 9P? What about the lack of stateful semantics?

Quotes

“Cookie/Set-Cookie is the worst specification ever. So many stupid details and broken aspects smashed into one tiny little header.” - Ian Bicking

HTTP 0.2 A sane web protocol is not an oxymoron