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.
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> 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> @ 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> @ 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.