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 lloyd.wood@xxxxxxxxxxx http://about.me/lloydwood > > > > ________________________________ > From: Michael Richardson <mcr+ietf@xxxxxxxxxxxx> > To: ietf@xxxxxxxx > 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 <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works > > -= IPv6 IoT consulting =- > >
Attachment:
signature.asc
Description: OpenPGP digital signature