W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

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

From: Roberto Peon <grmocg@gmail.com>
Date: Thu, 24 Jan 2013 14:25:28 -0800
Message-ID: <CAP+FsNfOE4MxwYOo9ELzmyAYH2dfMLJi0mrOnKCUvsL34Sv9Qw@mail.gmail.com>
To: Yoav Nir <ynir@checkpoint.com>
Cc: Nico Williams <nico@cryptonector.com>, Phillip Hallam-Baker <hallam@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
And by "people who don't want" I mean implementors who don't wish to
implement the full-set of HTTP/2 features, even when many of them get out
of the way when you don't want 'em (e.g. the proposed compression stuff).
-=R


On Thu, Jan 24, 2013 at 2:23 PM, Roberto Peon <grmocg@gmail.com> wrote:

> 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
>>
>>
>>
>
Received on Thursday, 24 January 2013 22:25:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 24 January 2013 22:25:59 GMT