Greg Wilkins wrote:
>
> All,
>
> another thing that I think would be helpful for implementing push is an
> event for when a response is committed, but before the content has been
> sent.
Just to clarify, do you mean that this will get called just before
anything has been written out to the client (including headers), or do
you intend for this to be called after the headers have been written out
but before the body?
If you mean the latter then I am against this, as it basically means
instead of being able to write out both the headers and body in a
gathering write we need to make two separate write calls, which sucks
from a performance point of view.
If you mean the former then I think this is a good idea, however I am
not sure about the name (as technically it will happen before the
response is commited). Also if this is called just before commit would
we allow the user to modify headers etc in this event?
Stuart
>
> This is the perfect time for a push algorithm to extract information
> about associated resources (size, etag, modified, session, set-cookies
> etc.) and also a great time to start doing pushed.
>
> If we try to implement push before commit, then we may not see a newly
> valid session or some authority token set in a cookie that needs to be
> used when creating the associated requests. If we delay later, then
> the client will have already received content and may have already
> issued requests for the associated resources.
>
> Would it be possible to add something like:
>
> interface ServletResponseListener
> {
> void responseCommitted(ServletResponseEvent event);
> }
>
> class ServletResponseEvent
> {
> ServletRequest getServletRequest() {...}
> ServletResponse getServletResponse() {...}
> }
>
> thoughts?
>
>
>
> On 28 November 2014 at 16:27, Greg Wilkins <gregw_at_intalio.com
> <mailto:gregw_at_intalio.com>> wrote:
>
>
> Hi all,
>
> I've had a few more thoughts on a HTTP Push API that benefit from a
> little more experience and experimentation.
>
> One of the proposals discussed was for an API that looked something
> like:
>
> response.push(uri)
>
> The issue with this are:
>
> 1. Cannot mutate headers and container will have to work out all
> the headers needed
> 2. Does not work for cross context pushing (not a huge loss, but
> breaks orthogonality of container)
>
> The alternative API that I proposed was
>
> servletContext.getRequestDispatcher(uri).push(request)
>
> which solves both the problems identified above as cross context can
> be used and a wrapped request to be pushed in if the headers need to
> be mutated.
>
> So this led me to start thinking what mutations are needed when
> generating the psuedo request that will be in the push promise and
> which is used to generate the pushed resource. There are actually
> quiet a few that I can think of:
>
> * If the base request contains a session ID in it's URI, then the
> pushed URIs need to be updated with a session ID.
> * If the requested session ID is for an invalid session, but
> getSession() returns a new valid session, then any session ID in
> the pushed request (either as cookie or uri param) should be the
> new session ID and not the old invalid one.
> * Conditional headers need to be removed/mutated as any etags or
> modified dates will relate to the base request and not the
> pushed resource.
> * Referer header should be set as the base resource, not the base
> resources referrer
> * Any digest authentication headers need to be removed as they
> apply only to the base request. We then need to decide if
> pushed requests need to be reauthenticated and/or reauthorised?
> * Perhaps the method needs to be mutated? Can we push GETs from POSTS?
> * Expect 100 headers removed
> * Range headers removed
> * Upgrade headers removed
>
>
> So this is a lot of mutating and filtering required to make a good
> pushed request and I'm sure there are complexities and interactions
> yet to be discovered that need to be handled. Thus I'm starting to
> think that passing in the request as the template is not really the
> best way to go:
>
> * as it will be a bit clumsy to have to wrap the request and then
> do all this mutating.
> * if left to the application, it is likely that many of these
> things will not be correctly handled
>
> Thus I'm leaning back to a simpler API where just the uri is passed
> and the container is responsible for doing all these kinds of
> mutations. Perhaps some kind of optional additional headers could
> be passed in?
>
> Anyway, in short, I think this mechanism is going to be a lot more
> complex and tricky to get right than I originally thought.
>
> 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.