Martin Thomson <martin.thomson@xxxxxxxxx> wrote:
> Are you looking to *standardize* these restrictions, or are you just
> asking what is possible?
Ideally, I'd reference a document which was something like "restricted http2"
or "http2 dumbed down to http1.1" or "http2 lite" or some such.
That document would get updated now and then to accomodate new issues.
> It's certainly possible to limit the number of concurrent streams,
> disable push, constrain flow control aggressively, and other things.
> Baking that into a standard would be unwise.
> If you are using HTTP and your protocol breaks when requests are sent
> and handled concurrently, that might indicate a problem with the usage
> and not something that you want to solve in the way you are
> suggesting.
We need one request to go through first, and then more or less, the rest
could be handled concurrently.
This is not really any different than the need to login to a web site
before you start making API requests. Of course, the unauthorized requests
will return 401 or some such, but it would be better not to confuse the
client which might think it's already done the authentication.
Really, it's all solvable up in the client with a state machine above HTTP2.
I'm just concerned that there might be things that HTTP2 might permit to
occur concurrently (that I don't know about, or maybe hasn't been defined
yet...) that HTTP1.1 would have serialized and not surprised anyone.
Let me know if I'm worried for naught.
> On Tue, Oct 3, 2017 at 2:58 PM, Michael Richardson
> <mcr+ietf@xxxxxxxxxxxx> wrote:
>>
>> 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 <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
>>
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =-
Attachment:
signature.asc
Description: PGP signature