Re: configuration violating J2EE spec?
Apparently, in weblogic (which is the server we are currently using) it is possible to "hardcode" the context-root into the weblogic.xml file (if not specified in the EAR application.xml file). All the sysadmin needs to do is let the request come through "unscathed" and we can at least remain underneath this "/apps" prefix, only now the equation Craig pointed out will be true. And yes, this is obviously a non-standard configuration since weblogic.xml is not a file from the J2EE spec, but at least it will be transparent to the J2EE apps. Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configuration violating J2EE spec? [Auf Viren geprüft]
[EMAIL PROTECTED] wrote: You may combine mod_rewrite and mod_proxy in Apache and do all kinds of wunderful and strange URL mangling things: That's all well and good, so long (AFAIK) as the original client's request is maintained when the servlet is called. Otherwise, as a servlet developer, I have to provide some other interface (e.g., a properties file containing the actual client scheme, port number, etc.). That's not a good solution because it duplicates parts of the request interface. I'm wondering if Oracle will get it right with 10g(as?). 10g is free for developer use and I could easily check. Anyone interested? - Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configuration violating J2EE spec? [Auf Viren geprüft]
You may combine mod_rewrite and mod_proxy in Apache and do all kinds of wunderful and strange URL mangling things: E.g. for all URLs ending in .jsp stripping the /apps/ in the path or for all *.jpg, *.gif, *.html beginning with /modulename/ addinf /apps/ before or even generate http subrequests to 2 internal Web-App-Servers and 3 internal Web-Servers, listening on different, non-standard ports. Did I mention that mod_proxy is not only able to work as a reverse-proxy, but for example may cache even dynamic pages for a specific amount of time driving up performance? (when it doesn't matter mus, if the page was updated 5 minutes ago) Frerk Meyer EDEKA Aktiengesellschaft GB Datenverarbeitung Frerk Meyer CC Web Technologien New-York-Ring 6 22297 Hamburg Tel: 040/6377 - 3272 Fax: 040/6377 - 41268 mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configuration violating J2EE spec?
On Wed, 18 Aug 2004 15:30:12 -0500, David Durham <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configuration violating J2EE spec?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configuration violating J2EE spec?
> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: configuration violating J2EE spec?
> -Original Message- > From: Craig McClanahan [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 18, 2004 1:19 PM > To: Struts Users Mailing List; [EMAIL PROTECTED] > Subject: Re: configuration violating J2EE spec? > > > On Wed, 18 Aug 2004 15:13:53 -0400, Dan Allen > <[EMAIL PROTECTED]> 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 It's not the configuration that needs to be investigate it's his sysadmins with a hot poker and a soldering iron I'm thinking Or at least point out that you have friends who program the payroll system. > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configuration violating J2EE spec?
On Wed, 18 Aug 2004 15:13:53 -0400, Dan Allen <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: configuration violating J2EE spec?
> -Original Message- > From: Dan Allen [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 18, 2004 1:09 PM > To: Struts Users Mailing List > Subject: Re: configuration violating J2EE spec? > > > > Web server (ie apache) or application server (ie tomcat). > Application server shouldn't be > > stripping off the context, and yes that would be a > violation. Web server stripping off > > context... well if you tell it. Our webserver doesn't > strip off context at all, because we tell it > > not to. If yours is, then yes your violating J2EE, but I > don't think it's necesarily the web > > servers fault. > > Just to clarify the configuration, the administrator of the servers > has it configured to that it *intentionally* strips off this portion > of the URL, hence my concern. It isn't the web server's fault since > it just does what it is told, but it is very much the fault of our > administrators. I need to make a point to them (so that I don't have > to live with hacked code) and I needed to get some backing from the > spec. For a moment I was thinking sword.. don't know why > > Does anyone know where I would find reference to this in the J2EE spec > so that I can flip to a page and say "there it is?" Tomcat reference has some info on context... and you're looking at the servlet part of the spec. http://jakarta.apache.org/tomcat/tomcat-5.0-doc/appdev/deployment.html Says: The complete syntax and semantics for the deployment descriptor is defined in Chapter 13 of the Servlet API Specification, version 2.3. Over time, it is expected that development tools will be provided that create and edit the deployment descriptor for you. In the meantime, to provide a starting point, a basic web.xml file is provided. This file includes comments that describe the purpose of each included element. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configuration violating J2EE spec?
> Web server (ie apache) or application server (ie tomcat). Application server > shouldn't be > stripping off the context, and yes that would be a violation. Web server stripping > off > context... well if you tell it. Our webserver doesn't strip off context at all, > because we tell it > not to. If yours is, then yes your violating J2EE, but I don't think it's > necesarily the web > servers fault. Just to clarify the configuration, the administrator of the servers has it configured to that it *intentionally* strips off this portion of the URL, hence my concern. It isn't the web server's fault since it just does what it is told, but it is very much the fault of our administrators. I need to make a point to them (so that I don't have to live with hacked code) and I needed to get some backing from the spec. Does anyone know where I would find reference to this in the J2EE spec so that I can flip to a page and say "there it is?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: configuration violating J2EE spec?
> -Original Message- > From: Dan Allen [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 18, 2004 12:14 PM > To: [EMAIL PROTECTED] > Subject: 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? Web server (ie apache) or application server (ie tomcat). Application server shouldn't be stripping off the context, and yes that would be a violation. Web server stripping off context... well if you tell it. Our webserver doesn't strip off context at all, because we tell it not to. If yours is, then yes your violating J2EE, but I don't think it's necesarily the web servers fault. > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
