Greg Wilkins wrote:
>
> I have incorporated some of the feedback received into Jetty's
> experimental implementation. You can see the PushBuilder (as a class
> rather than interface) here:
>
> http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-server/src/main/java/org/eclipse/jetty/server/PushBuilder.java
>
> and the push methods on request are seen at
> http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-server/src/main/java/org/eclipse/jetty/server/Request.java#n218
>
> and a filter that utilizes the API is
> http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-servlets/src/main/java/org/eclipse/jetty/servlets/PushSessionCacheFilter.java
>
> I'm going to now gather some experience using this on our live site.
> I think further progress on making this the start of a proposed standard
> API will probably need to wait until other implementations catch up with
> using/implementing push.
I updated
https://http2.undertow.io to enable push today (with a nasty hack to work around IE's push support issues), using a similar kind of handler that learns over time.
Something that did occur to me that there is a real possibility of different layers generating the same push request, e.g. if you have something like Greg's filter that learn's over time, and you have user code that pushes based on what it knows is going to be requested there is a good chance they will both generate the same push (this happened to me today, as my directory listing rendering code was already pushing the css).
I'm not sure how to best deal with this, the obvious way is to just ignore a push for the same resource after the first has been sent, although in this case the later response will be from the application layer which should have more information. Maybe we should make implementations queue the pushes until headers are sent and then send the last push for each path?
Stuart
>
> cheers
>
>
>
> On 9 December 2014 at 07:44, Greg Wilkins <gregw_at_intalio.com
> <mailto:gregw_at_intalio.com>> wrote:
>
>
>
> On 8 December 2014 at 21:42, Edward Burns <edward.burns_at_oracle.com
> <mailto:edward.burns_at_oracle.com>> wrote:
>
> > >>>> On Fri, 5 Dec 2014 11:52:01 +0100, Greg Wilkins
> <gregw_at_intalio.com <mailto:gregw_at_intalio.com>> said:
>
> GW> I've been working with Push a little bit more and have an
> alternative
> GW> proposal for the API.
>
> Well, I'm sorry to see the simplicity of the existing API have
> to give
> way to something that seems to be starting to get quite complex.
>
> GW> I've started work on this, but thought I'd seek some
> feedback before I
> GW> commit too much effort. The idea is that often there will
> be many
> GW> resources to push and that a lot of the work needed to work
> out headers,
> GW> sessions and cookies is common to all the pushes. So we
> need a new
> GW> PushBuilder instance that does all this work once. We
> would obtain a
> GW> PushBuilder from a new method on the request:
>
> GW> /** Get a PushBuilder associated with this request
> initialized as
> GW> follows:<ul>
> GW> * <li>The method is initialized to "GET"</li>
>
> If we obtain the PushBuilder from the current request, then why
> would
> the method not be taken on from the existing request?
>
>
> Because we cannot push POSTs and PUTs. We can push GETs and HEAD,
> maybe even OPTION and these can be pushed in association with a POST
> (can't think why a PUT would have push associates).
>
> So just trying to come up with a default that will work with minimal
> calls for most situations. Maybe it is initialised to the same
> method as the original request, unless that method is not supported
> by push, in which case it is initialised to GET.
>
> [...]
>
> GW> * <p>Each call to getPushBuilder() will return a new
> instance
> GW> * of a PushBuilder based off this Request. Any
> mutations to the
> GW> * returned PushBuilder are not reflected on future returns.
> GW> * @return A new PushBuilder or null if push is not
> supported
> GW> */
> GW> public PushBuilder getPushBuilder()
>
> I to prefer the isPushSupported() method. I think calling
> getPushBuilder() should throw IllegalStateException if push is not
> supported.
>
>
> Sounds like a converging consensus on that.
>
> cheers
>
>
>
> --
> Greg Wilkins <gregw_at_intalio.com <mailto:gregw_at_intalio.com>> @
> Webtide - /an Intalio subsidiary/
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client
> that scales
> http://www.webtide.com advice and support for jetty and cometd.
>
>
>
>
> --
> Greg Wilkins <gregw_at_intalio.com <mailto:gregw_at_intalio.com>> @ Webtide
> - /an Intalio subsidiary/
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
> http://www.webtide.com advice and support for jetty and cometd.