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

Well, the web has changed a lot since its inception when pages were mostly
a single resource. Now, we're nearly fetching a 100 resources per page, and
myriad people make money from it.
I think that the decision to ignore compression in the beginning was a
correct one. Now, however, the headers are causing more than acceptable
latency impediments to page loads, especially on the devices which are
becoming the most prevalent (mobile devices with relatively high latency,
and low bandwidth).

I'm still confused about how what has been proposed would force WebServices
to fork.
Placing myself in your and Nico's imagined shoes, it still sounds like
forking would take more effort than taking someone's compression library
and hooking it in as appropriate, especially given that the overall memory
and CPU cost of doing so would be between negligible and zero.

Are you worried about devices with extremely limited code-space/memory?

-=R


On Thu, Jan 24, 2013 at 2:36 PM, Phillip Hallam-Baker <hallam@gmail.com>wrote:

> So don't do header compression, do a tokenization approach that does not
> cause Web Services to fork.
>
> If Web Services can't use 2.0 then you have forked the protocol whether
> they do that by continuing to use 1.1 or by developing a new protocol.
>
> Not that there would be any difference in practice since if HTTP/2.0 does
> not support Web Services in a sane fashion there will eventually be a 2.0
> for Web Services.
>
>
> We did know about compression libraries back in '92. Latency was a much
> bigger concern back in those days when the whole of CERN was hanging off a
> not much more than a T1 and we had 10base ethernet.
>
> The idea of header compression was rejected back then as a silly
> optimization and I really can't understand why anyone thinks the situation
> has changed to make it less silly.
>
> On Thu, Jan 24, 2013 at 5: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
>>>
>>>
>>>
>>
>
>
> --
> Website: http://hallambaker.com/
>