[jsr369-experts] HTTP Push, URI and header mutations

From: Greg Wilkins <gregw_at_intalio.com>
Date: Fri, 28 Nov 2014 16:27:11 +1100

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:


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


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

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.


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.