Subject: HTTP/2 Push deployed on webtide.com

From: Simone Bordet <[email-masked]>
Date: Mon, 18 Aug 2014 10:57:59 +0200

Hi,

the Jetty team has deployed h2-14 with HTTP/2 Push functionality on
https://webtide.com, see
https://webtide.com/http2-push-with-experimental-servlet-api/.

We are very interested in comments about how to make HTTP/2 Push
better, so please try it out and tell us (also see discussion bullets
towards the end of blog post).

Thanks !

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
http://intalio.com
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 19 Aug 2014 09:55:04 +1000

Note that there is a thread on the Servlet EG list regarding an API for
push:

https://java.net/projects/servlet-spec/lists/jsr340-experts/archive/2014-08/message/1

where I've been asked some questions to describe "the rationalization used
by the httpbis wg"

Since I can't speak for the WG, I thought I'd echo my thoughts here
regarding the push mechanism to check that I'm not misrepresenting anything:

   - Push is a server-side coordinated mechanism in as much as the server
   must decide to push a resourced based only on information that it already
   has.   Specifically h2 provides no information on the contents or status of
   downstream caches.
   - Servers are free to innovate push strategies, with some of the
   following having been suggested:
      - Use knowledge from the web application/framework to determine what
      are associated resources.
      - Use heuristics derived from referrer headers and timing to infer
      what are associated resources
      - Use sessions to track what resources a client has
      requested/received to avoid unnecessary pushes
      - Use the presence of if-modified headers to infer the status of a
      client cache to avoid unnecessary pushes.
      - There are no functional problems other than increased latency of
   not pushing an associated resource
   - There are no functional problems other than wasted bandwidth of
   pushing an unnecessary resource:
      - Clients can reset a pushed stream if they determine it is
      unnecessary.   Thus is a server attempts to push a resource that
is already
      cached by the client, a RST will prevent wasting too much bandwidth.

Hopefully nothing controversial or misrepresented there?

cheers

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Aug 2014 10:45:11 +1000

My .02 - that seems to sum it up pretty well.

Cheers,

On 19 Aug 2014, at 9:55 am, Greg Wilkins <[email-masked]> wrote:

> 
> Note that there is a thread on the Servlet EG list regarding an API for push:
> 
> where I've been asked some questions to describe "the rationalization used by the httpbis wg"
> 
> Since I can't speak for the WG, I thought I'd echo my thoughts here regarding the push mechanism to check that I'm not misrepresenting anything:
> 	• Push is a server-side coordinated mechanism in as much as the server must decide to push a resourced based only on information that it already has.   Specifically h2 provides no information on the contents or status of downstream caches.   
> 	• Servers are free to innovate push strategies, with some of the following having been suggested:
> 		• Use knowledge from the web application/framework to determine what are associated resources.
> 		• Use heuristics derived from referrer headers and timing to infer what are associated resources
> 		• Use sessions to track what resources a client has requested/received to avoid unnecessary pushes 
> 		• Use the presence of if-modified headers to infer the status of a client cache to avoid unnecessary pushes.
> 	• There are no functional problems other than increased latency of not pushing an associated resource
> 	• There are no functional problems other than wasted bandwidth of pushing an unnecessary resource:
> 		• Clients can reset a pushed stream if they determine it is unnecessary.   Thus is a server attempts to push a resource that is already cached by the client, a RST will prevent wasting too much bandwidth.
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: "Martin Nilsson" <[email-masked]>
Date: Tue, 19 Aug 2014 15:30:07 +0200

On Tue, 19 Aug 2014 01:55:04 +0200, Greg Wilkins <[email-masked]> wrote:

> There are no functional problems other than wasted bandwidth of pushing  
> an unnecessary resource:
Wasted bandwidth and increased latency of subsequent resources, if any.

/Martin Nilsson

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/