Re: HTTP/QUIC Diverging from HTTP/2

Hello Mike,

I have server implementations of SPDY and then later HTTP/2, which was
supposed to be very close to SPDY with just a few refinements. Well it
turned out that these "minor refinements" of HTTP/2 required a completely
different software architecture. If I had known from the outset that HTTP/2
was that different from SPDY, I could have saved some time by implementing
HTTP/2 from scratch on first instance.

We have also considered to implement QUIC for a time, but the protocol and
the draft describing it look quite complex, and this thing of QUIC being a
transport for HTTP/2 being a transport for HTTP/1 doesn't make it easier.
So my dream scenario would be to have a standard which only mentions HTTP/2
in passing. Of course QUIC being a transport for HTTP/1 semantics is
completely acceptable and to a point, expected.




On Thu, Mar 9, 2017 at 7:53 PM, Mike Bishop <Michael.Bishop@microsoft.com>
wrote:

> At Patrick’s suggestion, I’m restating this question and addressing it to
> both the HTTP and QUIC working groups.  Apologies if you’re already
> following along in QUIC and get this twice after having already seen it the
> first time.
>
>
>
> HTTP/QUIC started off (draft -00) with a mostly-complete HTTP/2 session on
> QUIC Stream 3, including a full HTTP/2 multiplexing layer within Stream 3.
> A number of HTTP/2 frames weren’t necessary, since they were duplicative of
> services QUIC provides.  In draft -01, we removed the full mux layer from
> Stream 3, instead letting QUIC deal with all the stream management.  This
> necessitated changes to several of the remaining frames.  By the current
> editor’s copy, *no* HTTP/2 frame exists unmodified in HTTP/QUIC, though
> several frames of the same name and purpose exist.  Likewise, RFC7540
> defines six settings, three of which are inapplicable in HTTP/QUIC.
>
>
>
> However, the draft currently still attempts to define them as close
> cousins.  It updates the HTTP/2 frame and setting registries with
> additional columns (HTTP/2, HTTP/QUIC, or Both?; HTTP/QUIC Specification if
> applicable) and attempts to coexist with HTTP/2 in the same registry.
> (QUIC defines a unified error space, which means a separate registry of
> error codes for HTTP/QUIC regardless.)
>
>
>
> In PR #363 <https://github.com/quicwg/base-drafts/pull/363>, I’ve
> consolidated almost all of the “different from HTTP/2” text into a new
> top-level section and excised a lot of “HTTP/2 has this, but HTTP/QUIC
> doesn’t need it” text from the main body of the document.  Martin has
> advocated making a clean break from HTTP/2 and defining our own IANA
> registry for frame types and settings, just as we already have for errors.
> We can, out of respect for our cousin, use the same values where
> appropriate and reserve existing values currently in use on the HTTP/2 side.
>
>
>
> I think that’s a good idea, and it’s a fairly small step from the current
> state of #363.  I’ve created PR #376
> <https://github.com/quicwg/base-drafts/pull/376> to actually make that
> split.
>
>
>
> Comments from both WGs about the two PRs would be welcome.  (Feedback so
> far from the QUIC side seems to mostly be “separate with regrets,” but not
> universally.)
>



-- 
Alcides Viamontes E.
Chief Executive Officer, Zunzun AB
(+46) 722294542
(www.shimmercat.com is a property of Zunzun AB)