- From: Yoav Nir <ynir@checkpoint.com>
- Date: Thu, 24 Jan 2013 22:19:50 +0000
- To: Roberto Peon <grmocg@gmail.com>
- CC: Nico Williams <nico@cryptonector.com>, Phillip Hallam-Baker <hallam@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
- Message-ID: <4613980CFC78314ABFD7F85CC3027721119908B4@IL-EX10.ad.checkpoint.com>
It might end up smaller than what you need for an HTTP/1 client. But that also allows us to implement just one protocol on the server for both full-capability and minimal clients. Similarly for full-capabilities client working with minimal servers. On Jan 25, 2013, at 12:08 AM, Roberto Peon <grmocg@gmail.com<mailto:grmocg@gmail.com>> wrote: So... why would someone who didn't want these things use HTTP/2 instead of HTTP/1? -=R On Thu, Jan 24, 2013 at 2:03 PM, Yoav Nir <ynir@checkpoint.com<mailto:ynir@checkpoint.com>> wrote: On Jan 24, 2013, at 9:01 PM, Nico Williams <nico@cryptonector.com<mailto:nico@cryptonector.com>> wrote: > On Thu, Jan 24, 2013 at 12:41 PM, William Chan (ιζΊζ) > <willchan@chromium.org<mailto:willchan@chromium.org>> wrote: >>> The main one is that the receiver has to have enough memory to store the >>> dictionary. >> >> I think this boils down to the argument on the other thread. Do the >> gains for keeping state outweigh the costs? Note that given Roberto's >> delta compression proposal, the sender can disable compression >> entirely, so the receiver does not need to maintain state. Browsers >> probably would not do this, due to our desire to optimize for web >> browsing speed. For web services where you control the client, you >> indeed would be able to disable compression. > > IMO we need stateful compression to be absolutely optional to > implement. (If we choose to go with stateful compression in the first > place. I think we shouldn't.) I think we need to do a little more. I think we should define a "minimal implementation" and have a way for client and server to signal this. A minimal implementation would not be able to do any or some of these: - compression - server-initiated streams - stream priority - credentials - all but a small set of headers. - multiple concurrent streams Maybe we need a CAPABILITIES control frame that will allow client or server to communicate to the other what capabilities they don't have. A truly minimal client would be capable of one stream at a time - really down to HTTP/1.0 functionality with the new syntax. Would this allow Phillip to use HTTP/2 for minimalist web services? Yoav Email secured by Check Point
Received on Thursday, 24 January 2013 22:20:24 UTC