Re: Starting HTTP/2.0 for HTTP - Upgrade

On Sat, Oct 5, 2013 at 5:06 AM, Salvatore Loreto <
salvatore.loreto@ericsson.com> wrote:

>
> while implementing the 06 draft we have discovered that
> when starting HTTP/2.0 for http with the Upgrade mechanism
> the client sends twice (according to Section 3.2)
>
> the first time it in the HTTP2-Settings header field and the second
>
>      GET /default.htm HTTP/1.1
>      Host: server.example.com
>      Connection: Upgrade, HTTP2-Settings
>      Upgrade: HTTP/2.0
>      HTTP2-Settings: <base64url encoding of HTTP/2.0 SETTINGS payload>
>
>
> the second is after the reception of the 101 response
>
>     Upon receiving the 101 response, the client sends a
>    connection header (Section 3.5), which includes a SETTINGS frame.
>
>
Good catch. Looks like we introduced this when adding the HTTP2-Settings. I
don't have a strong opinion here on how to fix (if we want to fix at all)
so I'll save my paint for other bikesheds.


>
> Another thing that we think should be clarified during starting HTTP/2.0
> (common to both the scenario http and http2)
> is related to the second to last paragraph of Section 3.5
>
>    To avoid unnecessary latency, clients are permitted to send
>    additional frames to the server immediately after sending the client
>    connection header, without waiting to receive the server connection
>    header.  It is important to note, however, that the server connection
>    header SETTINGS frame might include parameters that necessarily alter
>    how a client is expected to communicate with the server.  Upon
>    receiving the SETTINGS frame, the client is expected to honor any
>    parameters established.
>
>
> in the paragraph it is not clear what happens (what should be the default
> behavior) if
> the server alter how a client is expected to communicate with the server.
> This ambiguity could lead to different server side implementations and
> then to
> unexpected behaviors
> It would be better to specif, to avoid vulnerability in server
> implementations, something like the following:
> "if the client exceeds any imitations of the server before the SETTINGS is
> understood by the client,
> the server SHOULD/MUST send GOAAWAY."
> an alternative to this proposal is that the server SHOULD enforce the
> local SETTINGS.
>

A peer is always going to enforce its known settings. If one side chooses
to update SETTINGS in the middle of the connection, the peer will always be
slightly out of sync. We should not treat SETTINGS violations as connection
errors. AFAICT, all defined settings have reasonable fallback scenarios
(that look to be unspecced, which we maybe should fix). That's acceptable,
although it's probably desirable to avoid it when possible. That's why
we've discussed stuff like HTTP2-Settings and settings in ALPN, in order to
eliminate those races when possible. In the HTTP/2 Upgrade scenario, it
seems to be that it'd be desirable for the client to wait for the server's
HTTP/2 connection header (not just the HTTP/1.X Upgrade response) before
starting to send any of its own frames, in order to prevent the race. This
should not incur any HTTP/2 level roundtrips, and hopefully not any
TCP/lower level roundtrips from CWND & what not.


>
> best regards
> Salvatore Loreto
>
> www.sloreto.com
>
>