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.