Eliot Lear <lear@xxxxxxxxx> wrote:
> This is properly RESTful.
In my opinion EST is not particularly RESTful, it does POSTs which return
bodies, rather than returning a Location: and allowing a cachable GET
afterwards.
> 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.
When you say "accelerator", do you mean a some kind of TCP proxy for
satellite use? Or do you mean a load balancer?
The situation where I can envision a problem would be where a client
is written, and it happens to work due to sequencing of HTTP/1.1.
But fails for HTTP2 concurrent operations.
The client is broken, I will not dispute that; part of what I'm asking here
is basically, should there be any considerations written?
The IoT profile for HTTP2 is very interesting because:
1) it does discuss many of the issues I'm concerned about.
2) it quite reasonably argues that HTTP2 is sufficiently lighter
weight thatn 1.1, that devices will appear that do http2,
and not 1.1.
That profile seems to assume that the constrained device will be the server,
not the client. I think that's probably realistic for many things.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =-
Attachment:
signature.asc
Description: PGP signature