Greg Wilkins wrote:
>
> Stuart,
>
> I agree that having multiple push strategies operating at once is going
> to be a problem and I definitely agree that it is not obvious how to
> best deal with it.
>
> Queuing the push promise until the headers are sent may help, but then I
> can also imagine frameworks that will be generating content dynamically
> and will want to push resources as the html is generated, so the headers
> will be long gone. If we say the container is responsible for duplicate
> elimination, then such frameworks could be very lazy. I'm going to
> ponder on this one some more.
My initial thoughts are to queue until header generation, preserving the
most recent, send all queued at commit time, and after that send
immediately and discard duplicates. There may well be some important use
cases this is missing though, I have not really thought it through.
Stuart
>
>
> cheers
>
>
>
>
>
> On 10 December 2014 at 11:42, Stuart Douglas <sdouglas_at_redhat.com
> <mailto:sdouglas_at_redhat.com>> wrote:
>
>
>
> 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>
> > <mailto: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>
> > <mailto: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>
> <mailto: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>
> <mailto: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>
> <mailto: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.