Dear Experts,
I recently had a programmer to do something like the following:
// inside servlet doGet()
ServletContext scMe = getServletContext()
ServletContext scOther = scMe.getContext("/other");
scOther.setAttribute("x", "1");
scOther.getRequestDispatcher("/").forward(req, res);
The developer was attempting to forward the request to another
application,
and pass along some internal information via context attributes. His
thinking was that the attributes would be a good way to conceal
some sensitive parameters as an alternative to exposing them in the
URL.
The forward was to the same local container. It didn't work. I wasn't
expecting
it work -- and also never saw anyone attempt his before either. Yet in
the
his defense, I find nothing in the API or Specification that would
prohibit
what he did.
In the 3.1 Specification, we have:
4.5: "Any attribute bound into a context is available to any other
servlet
that is part of the same Web application."
OK, nothing limiting here. Placing an attribute in another
application's
context makes it available to any other servlet in that application.
It's
talking about "a context" not "the current context".
4.5.1: "Context attributes are local to the JVM in which they were
created.
This prevents ServletContext attributes from being a shared memory
store
in a distributed container"
OK, both contexts are in the same JVM.
Based on my readings, passing context attributes within one JVM between
applications should be allowed. I do not see any language prohibiting
this.
What are your expert opinions on what should be allowed? And is the
API explicit enough to allow/disallow the situation?
Regarding the API docs, there is a warning on
ServletRequest::setAttribute
regarding cross-application usage. There is no such warning on the
ServletContext::setAttribute. The warning is actually stuffed up in the
class documentation so it's easy to miss... but even then, my situation
doesn't fall under a "distributed container".
Thanks,
Paul