You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Dan Allen <da...@gmail.com> on 2004/08/18 21:13:53 UTC
configuration violating J2EE spec?
Before I go paging through the J2EE spec to find a defense, I want to
see if someone out there can offer advice in the following matter. In
our application, the configuration of the servers is such that any URL
with a context of "/apps/" is captured by the webserver, the URL is
rewritten with this context stripped and the resulting URL is passed
internally to the J2EE application server. For all intents and
purposes, the app server assumes that the URL requested was without
the "/apps/" context and processes the servlet mapping as such.
However, when the taglibs generate URLs, the "/apps/" portion is not
prepended and therefore a followup request by the client will not be
processed by the app server. Is this in violation of the J2EE spec
for the webserver to alter the URLs in this way?
client
(requests http://hostname/apps/modulename/)
webserver
(rewrites internally to http://hostname/modulename/)
app server
(generates http://hostname/modulename/somefile.jsp)
client
(requests http://hostname/modulename/somefile.jsp)
webserver
(throws 404 error)
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: configuration violating J2EE spec?
Posted by Dan Allen <da...@gmail.com>.
> See Section SRV.4.4 of the Servlet Spec. In brief, and modulo URL
> encoding differences, the following equation is required to be true:
>
> requestURI = contextPath + servletPath + pathInfo
Thanks Craig! That definitely saved me time. I have full confidence
that with this information I will win my case. I brought this to the
attention of the list because it is important information (and so that
when I move on to another job, hopefully the good readers of this list
will have updated their configurations so that I don't have to deal
with these bogus configurations again).
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: configuration violating J2EE spec?
Posted by Craig McClanahan <cr...@gmail.com>.
On Wed, 18 Aug 2004 15:30:12 -0500, David Durham
<da...@scott.af.mil> wrote:
> Craig McClanahan wrote:
>
> > ...
> > URI seen by the application properly reflects the one that the client
> > sent, not the one that was internally passed from the proxy.
>
>
> What about a scenario where the proxy ends up mangling such details as
> the protocol. Specifically, Oracle 9ias' proxy has a nasty habit of
> changing a client's https request into an http request. Is this type of
> thing also counter to the specifications?
>
I should be more clear, to avoid confusion.
It's perfectly legal for the proxy to mangle things like this as part
of its internal processing, AS LONG AS the values returned by the
following HttpServletRequest calls reflect what the original requestor
actually sent:
* getProtocol()
* getScheme()
* getServerName()
* getServerPort()
* getRequestURI()
* getContextPath()
* getServletPath()
* getPathInfo()
In other words, there needs to be some mechanism by which the proxy
and the servlet container communicate so that the original information
from the request is preserved, for use by the application. One way to
implement that, for example, would be to have the proxy add some
additional private HTTP headers to the forwarded message, so that the
servlet container could use those values to make its
HttpServletRequest object give the correct answers.
So, in your scenario above about converting https to http requests
internally, that is perfectly legal as long as the getScheme() method
still returns "https" to the web application responding to the request
-- since that is the way the request originally entered the server.
If you get an argument on this point, just go to the javadocs for the
getScheme() method:
Returns the name of the scheme used to make this request.
You'll see similar language on the other relevant methods.
There are circumstances where a proxied application wants to know both
what original request asked for, and where the proxy server sent the
request. Thus, in Servlet 2.4, the following methods were added to
identify the internal processing characteristics:
* getLocalAddr()
* getLocalName()
* getLocalPort()
> - Dave
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: configuration violating J2EE spec?
Posted by David Durham <da...@scott.af.mil>.
Craig McClanahan wrote:
> ...
> URI seen by the application properly reflects the one that the client
> sent, not the one that was internally passed from the proxy.
What about a scenario where the proxy ends up mangling such details as
the protocol. Specifically, Oracle 9ias' proxy has a nasty habit of
changing a client's https request into an http request. Is this type of
thing also counter to the specifications?
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: configuration violating J2EE spec?
Posted by Craig McClanahan <cr...@gmail.com>.
On Wed, 18 Aug 2004 15:13:53 -0400, Dan Allen <da...@gmail.com> wrote:
> Before I go paging through the J2EE spec to find a defense, I want to
> see if someone out there can offer advice in the following matter. In
> our application, the configuration of the servers is such that any URL
> with a context of "/apps/" is captured by the webserver, the URL is
> rewritten with this context stripped and the resulting URL is passed
> internally to the J2EE application server. For all intents and
> purposes, the app server assumes that the URL requested was without
> the "/apps/" context and processes the servlet mapping as such.
> However, when the taglibs generate URLs, the "/apps/" portion is not
> prepended and therefore a followup request by the client will not be
> processed by the app server. Is this in violation of the J2EE spec
> for the webserver to alter the URLs in this way?
>
> client
> (requests http://hostname/apps/modulename/)
> webserver
> (rewrites internally to http://hostname/modulename/)
> app server
> (generates http://hostname/modulename/somefile.jsp)
> client
> (requests http://hostname/modulename/somefile.jsp)
> webserver
> (throws 404 error)
>
> Dan
>
See Section SRV.4.4 of the Servlet Spec. In brief, and modulo URL
encoding differences, the following equation is required to be true:
requestURI = contextPath + servletPath + pathInfo
where requestURI is the portion of the URL after the host and port.
*All* servlet-API based technologies (including Struts, and including
tag libraries) rely on this equation being true so that they can
construct URIs to other resources in the same web application.
Therefore, an app server (which includes a front-end proxy if you're
using one) that lies to you, as in your scenario above, is broken.
You should investigate configuration settings in your server that
would let you compensate for this sort of thing, so that the request
URI seen by the application properly reflects the one that the client
sent, not the one that was internally passed from the proxy.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org