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

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/