Re: Make HTTP 2.0 message/transport format agnostic

Kevin--


You've described part of what SPDY already does and something which is
certainly a requirement for anything that meets HTTP's base semantics.
Unfortunately, you need to carry more than just the information you
provided if you wish to use the rest of HTTP's semantics such as auth (even
the crappy auth we currently have), cookies, caching, compression, etc.

And then there are the features that improve speed, like multiplexing, and
compression... The Chrome and FF code is open, as is the code for many
server implementations (including a number of 'toy' servers that are
perhaps easier to hack on).

Much of our experience with SPDY was hard fought and hard learned by
attempting, failing, and learning from the failure.

-=R

On Fri, Mar 30, 2012 at 2:46 AM, Kevin Cathcart <kevincathcart@gmail.com>wrote:

> I'm not really sure why everybody is getting so worked up about SPDY.
> The correct thing to do is pretty obvious
> to me. Document the core HTTP protocol in a message format agnostic
> way. This means not specifying
> the format of the messages or the transport.
>
> Instead the core HTTP spec would be defined in terms of two types of
> abstract messages. One is a request
> message, which includes the following components: a version number, a
> resource URI, a method, headers,
> and an optional body. The other message is a response, which includes
> a version, a status code, a status
> phrase, headers, and an optional body. The core spec would then define
> the meaning of the methods and
> headers, the rules regarding proxies and caching, and the
> authentication rules, etc. Basically everything
> that would apply to all message/transport formats.
>
> Separate specifications would define message/transport formats.
>
> Headers that are specific to the textual Internet Message
> message/transport format currently used in
> HTTP/1.1 would not be included in the core specification but would be
> part of a separate specification
> that would define the textual format for HTTP 2.0 (unless of course we
> decide not to support such a
> format for HTTP 2.0).
>
> SPDY could pretty trivially be such a message/transport format,
> requiring only slight tweaks to its specification
> like specifying that it presents its ":host" pseduo-header to as a
> Host header in the abstract message.
>
> Similarly we could define a S+M based message/transport format, or
> perhaps even a hybrid of the the two, whatever
> is deemed best.
>
> Kevin Cathcart
>
>
>
>