Re: should we specify HTTP/1.1 now that HTTP2 is out?

[Eliot Lear <[e-mail]>]

This is properly RESTful.


On 10/4/17 3:34 AM, Lloyd Wood wrote:
> Based on experience, I would say that the state issues
> will likely occur with TCP accelerators over a satellite
> link.
>
> HTTP/1.1 isn't as deterministic as you would like to
> think once an accelerator with prefetching is involved,
> and this can break the assumptions of security protocols
> layered over HTTP/1.1.
>
> If you're really properly RESTful, this shouldn't be
> an issue, of course...
>  
> Lloyd Wood [e-mail] http://about.me/lloydwood 
>
>
>
> ________________________________
> From: Michael Richardson <[e-mail]>
> To: [e-mail] 
> Sent: Wednesday, 4 October 2017, 8:58
> Subject: should we specify HTTP/1.1 now that HTTP2 is out?
>
>
>
>
> I'm seeking guidance.  It might be that this is a job for lwig, or perhaps
>
> there is already a document which details how to do the profiling I care
>
> about.  If so, please point me at that.
>
>
> In ANIMA's BRSKI protocol, which is based upon RFC7030 EST, we run over HTTP
>
> 1.1 today using a single TCP connection.
>
> It's HTTP over TLS ("HTTPS") [h2c?] rather than an upgrade.
>
>
> In BRSKI there are state issues with both the TLS and the HTTP process.
>
> The TLS server certificate is not trusted by the client until after at least
>
> one RESTful interaction occurs.  Only once that has occured is the connection
>
> considered secure.
>
>
> We are concerned about how the protocol could become broken if used with
>
> HTTP2 with interleaving of requests/responses.   With HTTP (port-80)
>
> transactions, using the RFC7540 section 3.2 upgrade, one could just decline
>
> to ever do the upgrade and be done.  With HTTPS, this is negotiated in
>
> the TLS connection, so one can go to HTTP2 directly, I think.
>
>
> While limiting ourselves to HTTP/1.1 might be a good policy, I worry that
>
> at some point in 10 years, the HTTP/1.1 code might be in the library only to
>
> support our use case, with the application code on the device having moved on
>
> to HTTP2 only.
>
>
> What I think we are looking for is a set of things we can specify that
>
> will make HTTP2 as deterministic (and slow!) as HTTP/1.1. For instance,
>
> I think that
>
>         SETTINGS_MAX_CONCURRENT_STREAMS = 1
>
>
> would do 90% of it.  Should we turn off PUSH?
>
> Can/should we recommend lower values for window sizes, etc?
>
> (ANIMA end points are not constrained in the IoT/RFC7228 sense, but rather
>
> are control plane CPUs, with megabytes of ram, often partitioned at boot
>
> time.  But, ANIMA BRSKI may also applies to Web connected devices like the
>
> baby monitors that have wreaked havoc.)
>
>
> --
>
> Michael Richardson <[e-mail]>, Sandelman Software Works
>
> -= IPv6 IoT consulting =-
>
>