On 05/12/2014 08:56, 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.
>
> 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?
I'm nowhere near as far ahead with my thinking about HTTP/2.0 as I'd
like to be at this point so this response is purely theoretical than
based on practical experience of implementing this.
I like this idea. It is simple and the justification makes sense to me.
Mark
>
>
>
> 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.