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

I think it's fairly certain that browsing web pages in the browser is the first class citizen here, and the page load times (relevant for web browsing) is the driver for the HTTP/2 effort.

There are other uses of HTTP:
 - web services
 - certificate RPs downloading CRLs or OCSP responses
 - media downloads / media streaming
 - software updates and downloads
 - Antivirus / IPS signature downloads
 - others

All these currently use HTTP and there's no reason for them to be "left behind" in HTTP/1.1. Some of SPDY's features, like server push and header compression are useless for most of these uses.

My goal in suggesting a minimal implementation definition is to allow implementers to create a small but compliant HTTP implementation that does not include all the bells and whistles, but can still get your software update to you. I think if we can get a 1000-2000 LoC C implementation of a simple fetcher can be written with compliant HTTP/2 support, that would be a good thing.

Yoav

On Jan 29, 2013, at 11:36 AM, Roberto Peon <grmocg@gmail.com<mailto:grmocg@gmail.com>>
 wrote:

Yes, video streaming, depending on how it is done*, could benefit from some of the features, especially prioritization...

*there are other protocols which are likely better suited to solving video-specific problems.
-=R


On Mon, Jan 28, 2013 at 10:50 AM, Hassnaa Moustafa <hassnaamoustafa@gmail.com<mailto:hassnaamoustafa@gmail.com>> wrote:
Hi,

I am just joining this discussion thread and I have a comment on what was mentioned by William "precisely the following text - copied from William's message below":

 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


 Hassnaa: Is video streaming considered one of the services for which HTTP2.0 could present a gain? or the focus right now is on web-browsing for the minimal implementation.

Regards,
Hassnaa



On Thu, Jan 24, 2013 at 2:19 PM, Yoav Nir <ynir@checkpoint.com<mailto: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<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






Email secured by Check Point