Re: Should Web Services be served by a different HTTP n+1?

That is the rub-- this forces complexity into every web-application by
forcing devlopers to have to do contingency and error cases for each
potentially optional parameter.
.. essentially, since people cannot rely upon it, they don't use it. This
happens today with HTTP/1 and it.. really sucks.

This doesn't seem like a good tradeoff when people who don't want these
things or the latency benefit can simply fall-back to HTTP/1

-=R


On Thu, Jan 24, 2013 at 2:19 PM, Yoav Nir <ynir@checkpoint.com> wrote:

>  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> 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> wrote:
>
>>
>> On Jan 24, 2013, at 9:01 PM, Nico Williams <nico@cryptonector.com> wrote:
>>
>> > On Thu, Jan 24, 2013 at 12:41 PM, William Chan (陈智昌)
>> > <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
>
>
>