- From: Jason Greene <jason.greene@redhat.com>
- Date: Wed, 25 Jun 2014 15:02:56 -0500
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: ietf-http-wg@w3.org
On Jun 24, 2014, at 3:01 AM, Amos Jeffries <squid3@treenet.co.nz> wrote: > On 24/06/2014 7:14 p.m., David Krauss wrote: >> >> On 2014–06–24, at 3:08 PM, David Krauss <potswa@gmail.com> wrote: >> >>> Also, stream initiation order is not preserved by intermediaries, so TCP’s guarantee is not strong enough. >> >> Oops, that’s too pathological to be possible. Still, PRIORITY has a purpose, although it might need a trial period as an extension. >> > > More accurately middleware can potentially be load balancing a given set > of streams over N backend servers. Any one of which at low-priority may > respond faster than a "high" priority server. Leading to sub-optimal > response frame ordering on the client connection regardless of request > sent order. Thats a good point. My mental model was focusing on execution ordering. I can see a benefit when you have data ready to ship on the response side, and ordering the frames in a particular way is helpful to the client. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Wednesday, 25 June 2014 20:06:36 UTC