You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Leggio, Andrew" <An...@mbia.com> on 2015/04/08 23:04:00 UTC

Rendering JSP files through Apache

I have the following being used in my conf file:

<IfModule mod_proxy_ajp.so>
  ProxyPass / ajp://localhost:8009/
</IfModule>

Does this actually direct jsp files to use Tomcat?


Andrew J. Leggio | MBIA Services Corporation | Assistant Vice President | Phone * (914) 765-3206 | Fax * (914) 765-3095 | * Andrew.Leggio@mbia.com<ma...@mbia.com>



------------------------------------------------------------------------------
This e-mail, including any attachments, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information.  If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of any part of this e-mail is strictly prohibited; please contact the sender and permanently delete the original and any copies of it.
------------------------------------------------------------------------------

Re: Rendering JSP files through Apache

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Andrew,

On 4/8/15 8:15 PM, Leggio, Andrew wrote:
> This contains both HTML and JSP.  I would like the HTML to be
> handled through Apache and JSP pages to be handled by TOMCAT.

Okay. Just curious: why?

> How do I accomplish this?

- From your other thread, it looks like you have solved this problem.
Are you still in fact having trouble?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVJncCAAoJEBzwKT+lPKRYcdYP/ieIeV/dyE2N7ymFYso6jy8g
UElbANv+2n3KwqfCe+ikDQJBOfXyVwxt1NesDC3vkwFHvvYqNJuMQgJNuDS2HpJz
KXAGYDJBIEokj6lcWrhs2bYzDpKwdN7ldUM70wXG4OZ/yrXvrhtHSKnikfGtJoyW
EWj1/HnHL21j7Hvzp3uHVrWMUDJbFDf+1BvIJJ/kA5orJ5fy01Tk0s+/BGeMkWuk
BotBaokxN4ttX7Z5VFfczEDYkfZ2OlmpaKDURaD2uyITaXy8KQ3SNdViLpyxdBaT
2Nh7cio1wCVfkn4FxkDps9Y9eBTRBHWKfZNyrV9xIPMSGc3soInQ0uWvGTTXyJAd
O6LahC/sA2fpT5MIayXUrjNQHOd3gUudrRPRD4O75JRTjPgg05tLiqZcYWkyDD91
BLriXIudPDbTt/Tw6Zq0PXrmTiIPSzdCLUNeznJWJuknhul86vYRs5luFORS1byu
lBIZNZq4us5bmHHk9ufME37uwV+P2f5bZAZBOv25XYszNgc1m0PdJxN/A+dOomPJ
Q+G52pKRXn+nNV/P2zZ9kZNC09ZnH8FnkzLXHnP9GVzAP2+OQ/klZJWDV3JxAkH7
JES4imdhADRypTntI34rqeN7vYSzQm7WTrbqHDyyXTK6WBtsytipf+dNiWfa10rL
ntPsrfPnR9xmRlnEZ4C2
=IXuZ
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Rendering JSP files through Apache

Posted by Mark Thomas <ma...@apache.org>.
On 09/04/2015 20:18, George Sexton wrote:
> 
> 
> On 4/9/2015 1:10 PM, David kerber wrote:
>> You can argue about whether it's smart to map servlets into .html, but
>>> again my reading of the spec is that unequivocally, if the request path
>>> matches a deployed context, the request must be routed to the
>>> context/container.
>>
>> Then your reading is incorrect.  The spec only applies to requests
>> that reach the container in the first place.  If something else
>> handles it before it reaches the container, the spec is not applicable.
>>
> 
> Allow me to re-quote the spec:
> 
> A ServletContext is rooted at a known path within a Web server. For
> example, a servlet context could be located at
> http://www.mycorp.com/catalog. All requests that begin with the /catalog
> request path, known as the context path, are routed to the Web
> application associated with the ServletContext.
> 
> The spec explicitly includes the phrase "known path within a web server"
> and it explicitly also states "All requests that begin with the /catalog
> request path, known as the context path, are routed to the Web
> application associated with the ServletContext."
> 
> I don't see any conditionals that would allow violation of this. Arguing
> otherwise is really not supported by the language.

<with my Servlet Expert Group member hat on>

You are misunderstanding the specification.

The specification only applies to requests that reach the Servlet
Container. (You can safely replace 'Web Server' above with 'Servlet
Container' in the text you quote).

If you want to be picky about it, even once you reach the Servlet
container that quote is not 100% accurate. The container is required (by
the HTTP spec that is referenced from the Servlet spec) to reject
mal-formed requests with a 400 response before they are passed to a Web
Application even if enough of the request is well-formed to determine
the intended Web Application.

As others have already stated:
- The Servlet specification does not care if you put a reverse proxy in
front of the Servlet Container.
- The Servlet specification does not care if a reverse proxy routes
requests that the Servlet Container could correctly handle elsewhere.

Once you insert a reverse proxy (or a load-balancer, or a firewall,
or...) you have a larger system and it is up to the designer of that
system to ensure that the components of the system work together as
desired. Yes, it is possible to break an application by inserting a
reverse proxy but that is just a broken system, not an specification
compliance issue.

Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Rendering JSP files through Apache

Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Thu, Apr 09, 2015 at 01:18:09PM -0600, George Sexton wrote:
> On 4/9/2015 1:10 PM, David kerber wrote:
> > You can argue about whether it's smart to map servlets into .html, but
> >> again my reading of the spec is that unequivocally, if the request path
> >> matches a deployed context, the request must be routed to the
> >> context/container.
> >
> > Then your reading is incorrect.  The spec only applies to requests 
> > that reach the container in the first place.  If something else 
> > handles it before it reaches the container, the spec is not applicable.
> >
> 
> Allow me to re-quote the spec:
> 
> A ServletContext is rooted at a known path within a Web server. For 
> example, a servlet context could be located at 
> http://www.mycorp.com/catalog. All requests that begin with the /catalog 
> request path, known as the context path, are routed to the Web 
> application associated with the ServletContext.
> 
> The spec explicitly includes the phrase "known path within a web server" 
> and it explicitly also states "All requests that begin with the /catalog 
> request path, known as the context path, are routed to the Web 
> application associated with the ServletContext."

In the context of Tomcat, "a web server" seems to mean Coyote, and as
far as I know Coyote is compliant with the spec.

> I don't see any conditionals that would allow violation of this. Arguing 
> otherwise is really not supported by the language.

There is no violation.  The web server in question never sees the
request, so as far as the spec. is concerned that request does not exist.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu

Re: Rendering JSP files through Apache

Posted by Mark Eggers <it...@yahoo.com.INVALID>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/9/2015 12:18 PM, George Sexton wrote:
> 
> 
> On 4/9/2015 1:10 PM, David kerber wrote:
>> You can argue about whether it's smart to map servlets into
>> .html, but
>>> again my reading of the spec is that unequivocally, if the 
>>> request path matches a deployed context, the request must be 
>>> routed to the context/container.
>> 
>> Then your reading is incorrect.  The spec only applies to
>> requests that reach the container in the first place.  If
>> something else handles it before it reaches the container, the
>> spec is not applicable.
>> 
> 
> Allow me to re-quote the spec:
> 
> A ServletContext is rooted at a known path within a Web server. For
> 
And the line above clearly states "Web server". Now the next question
is, what is a "Web server"?

- From a browser's point of view, that's whatever serves up a URL that
select.

- From a systems point of view, that can be:

1. a paired hardware load balancer that handles SSL
   plus
2. a group of Apache web servers that handles PHP, Perl, etc.
   plus
3. A collection of Tomcat servlet containers for JSP / Servlets, etc.
   plus
4. A database farm

- From a component point of view, that can be:

1. hardware load balancers
2. multiple Apache HTTPD servers
3. possible authentication / authorization servers
4. multiple Apache Tomcat servers
5. multiple database servers (SQL, noSQL, etc.)

- From my reading, the specification only applies to item 4 in the
components view.

Other than that, it's up to the systems architect to get it right.

> example, a servlet context could be located at 
> http://www.mycorp.com/catalog. All requests that begin with the 
> /catalog request path, known as the context path, are routed to
> the Web application associated with the ServletContext.
> 
> The spec explicitly includes the phrase "known path within a web 
> server" and it explicitly also states "All requests that begin
> with the /catalog request path, known as the context path, are
> routed to the Web application associated with the ServletContext."
> 
> I don't see any conditionals that would allow violation of this. 
> Arguing otherwise is really not supported by the language.
> 
>> 
>>> There are a lot of legitimate reasons to map "static"
>>> resources into servlets. Things like images, graphs, CSS files,
>>> Javascript files, etc.
>> 
>> Certainly, and that's what I do.  But it's for convenience and
>> ease of configuration, not because it's what the spec requires.
>> Other people have other needs...

. . . just my two cents
/mde/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJVJtLqAAoJEEFGbsYNeTwtmUkH/RFIPAZZHOXsLSOAT4PEl6Lm
RMuLnGWztFMR9ITc6DIikjRV2JIas3If8sCucE85LM/+3GWHDp1/HIJuXB073exZ
sWp2GSlS1ZYloyqnHGBq31783LdM/xpj0yrTlWWSYN7iVwxD+fd5dAxBYaFqxoxd
kh6DEQUld1ELBku2bXSf/4EcPFgPvhkGjvxbot1DQYO+CurHoFGRAnyrsQ17LJ3m
Hzm7fo7If1Gowm5EqNhjqPoSIpz8QHvZG0hZSZxg+B260D6RLbcdqpGuFLOZeOjA
WcJy+5dYydOxiF+pIFsA14OmEtPvxQsgQMOdTasskiubY60YcQXzvqZfe/7GnBU=
=1PCa
-----END PGP SIGNATURE-----

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Rendering JSP files through Apache

Posted by David kerber <dc...@verizon.net>.
On 4/9/2015 3:18 PM, George Sexton wrote:
>
>
> On 4/9/2015 1:10 PM, David kerber wrote:
>> You can argue about whether it's smart to map servlets into .html, but
>>> again my reading of the spec is that unequivocally, if the request path
>>> matches a deployed context, the request must be routed to the
>>> context/container.
>>
>> Then your reading is incorrect.  The spec only applies to requests
>> that reach the container in the first place.  If something else
>> handles it before it reaches the container, the spec is not applicable.
>>
>
> Allow me to re-quote the spec:
>
> A ServletContext is rooted at a known path within a Web server. For
> example, a servlet context could be located at
> http://www.mycorp.com/catalog. All requests that begin with the /catalog
> request path, known as the context path, are routed to the Web
> application associated with the ServletContext.
>
> The spec explicitly includes the phrase "known path within a web server"
> and it explicitly also states "All requests that begin with the /catalog
> request path, known as the context path, are routed to the Web
> application associated with the ServletContext."
>
> I don't see any conditionals that would allow violation of this. Arguing
> otherwise is really not supported by the language.

There is no violation of this if a request never reaches the container 
in the first place.  The spec only applies to the servlet container 
itself, not to the overall system of which it might be a part.


>
>>
>>> There are a lot of legitimate reasons to map "static" resources into
>>> servlets. Things like images, graphs, CSS files, Javascript files, etc.
>>
>> Certainly, and that's what I do.  But it's for convenience and ease of
>> configuration, not because it's what the spec requires. Other people
>> have other needs...
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Rendering JSP files through Apache

Posted by George Sexton <ge...@mhsoftware.com>.

On 4/9/2015 1:10 PM, David kerber wrote:
> You can argue about whether it's smart to map servlets into .html, but
>> again my reading of the spec is that unequivocally, if the request path
>> matches a deployed context, the request must be routed to the
>> context/container.
>
> Then your reading is incorrect.  The spec only applies to requests 
> that reach the container in the first place.  If something else 
> handles it before it reaches the container, the spec is not applicable.
>

Allow me to re-quote the spec:

A ServletContext is rooted at a known path within a Web server. For 
example, a servlet context could be located at 
http://www.mycorp.com/catalog. All requests that begin with the /catalog 
request path, known as the context path, are routed to the Web 
application associated with the ServletContext.

The spec explicitly includes the phrase "known path within a web server" 
and it explicitly also states "All requests that begin with the /catalog 
request path, known as the context path, are routed to the Web 
application associated with the ServletContext."

I don't see any conditionals that would allow violation of this. Arguing 
otherwise is really not supported by the language.

>
>> There are a lot of legitimate reasons to map "static" resources into
>> servlets. Things like images, graphs, CSS files, Javascript files, etc.
>
> Certainly, and that's what I do.  But it's for convenience and ease of 
> configuration, not because it's what the spec requires. Other people 
> have other needs...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>

-- 
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com

Re: Rendering JSP files through Apache

Posted by David kerber <dc...@verizon.net>.
On 4/9/2015 3:03 PM, George Sexton wrote:
>
>
> On 4/9/2015 10:06 AM, Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> George,
>>
>> On 4/9/15 10:52 AM, George Sexton wrote:
>>> On 4/8/2015 6:15 PM, Leggio, Andrew wrote:
>>>> This contains both HTML and JSP.  I would like the HTML to be
>>>> handled through Apache and JSP pages to be handled by TOMCAT.
>>>> How do I accomplish this?
>>> Just my two cents, but any server that works the way you want is
>>> not compliant with the servlet specification. It states that all
>>> requests for a context must be passed to the container.
>> ??
>>
>> The servlet spec doesn't apply to environments, only containers. If
>> the OP wants to have Apache httpd serve static files and proxy dynamic
>> requests, that's perfectly reasonable.
>>
>> It's also easy to do.
>>
>>> What you're suggesting is what GoDaddy does. The problem is that if
>>> you map requests for things like css, javascript, or even ".html"
>>> pages to a servlet, then it breaks.
>>>
>>> Bad idea.
>> ?
>>
>> Why would a servlet have a problem handling a request for a .html
>> file? The DefaultServlet was designed with that explicit purpose in mind
>
> What I'm saying is that having httpd handle request for .html and
> everything else handled by the servlet container violates section 4.1 of
> Java Servlet Specification 3.0.
>
> The issue is not the servlet handling the request for .html. The issue
> is that if the deployment descriptor has an explicit mapping for
> /context/foo.html, and the web app is never presented with the request
> because it's being done at the higher level of Apache httpd, then it
> breaks the web app. httpd is given the request for /context/foo.html,
> and there is no corresponding file, and the web app is broken.
>
> You can argue about whether it's smart to map servlets into .html, but
> again my reading of the spec is that unequivocally, if the request path
> matches a deployed context, the request must be routed to the
> context/container.

Then your reading is incorrect.  The spec only applies to requests that 
reach the container in the first place.  If something else handles it 
before it reaches the container, the spec is not applicable.


> There are a lot of legitimate reasons to map "static" resources into
> servlets. Things like images, graphs, CSS files, Javascript files, etc.

Certainly, and that's what I do.  But it's for convenience and ease of 
configuration, not because it's what the spec requires.  Other people 
have other needs...


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Rendering JSP files through Apache

Posted by George Sexton <ge...@mhsoftware.com>.

On 4/9/2015 10:06 AM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> George,
>
> On 4/9/15 10:52 AM, George Sexton wrote:
>> On 4/8/2015 6:15 PM, Leggio, Andrew wrote:
>>> This contains both HTML and JSP.  I would like the HTML to be
>>> handled through Apache and JSP pages to be handled by TOMCAT.
>>> How do I accomplish this?
>> Just my two cents, but any server that works the way you want is
>> not compliant with the servlet specification. It states that all
>> requests for a context must be passed to the container.
> ??
>
> The servlet spec doesn't apply to environments, only containers. If
> the OP wants to have Apache httpd serve static files and proxy dynamic
> requests, that's perfectly reasonable.
>
> It's also easy to do.
>
>> What you're suggesting is what GoDaddy does. The problem is that if
>> you map requests for things like css, javascript, or even ".html"
>> pages to a servlet, then it breaks.
>>
>> Bad idea.
> ?
>
> Why would a servlet have a problem handling a request for a .html
> file? The DefaultServlet was designed with that explicit purpose in mind

What I'm saying is that having httpd handle request for .html and 
everything else handled by the servlet container violates section 4.1 of 
Java Servlet Specification 3.0.

The issue is not the servlet handling the request for .html. The issue 
is that if the deployment descriptor has an explicit mapping for 
/context/foo.html, and the web app is never presented with the request 
because it's being done at the higher level of Apache httpd, then it 
breaks the web app. httpd is given the request for /context/foo.html, 
and there is no corresponding file, and the web app is broken.

You can argue about whether it's smart to map servlets into .html, but 
again my reading of the spec is that unequivocally, if the request path 
matches a deployed context, the request must be routed to the 
context/container.

There are a lot of legitimate reasons to map "static" resources into 
servlets. Things like images, graphs, CSS files, Javascript files, etc.

> .
>
> - -chris
>


-- 
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com

Re: Rendering JSP files through Apache

Posted by David kerber <dc...@verizon.net>.
On 4/9/2015 3:06 PM, George Sexton wrote:
>
>
> On 4/9/2015 12:58 PM, Caldarale, Charles R wrote:
>>> From: George Sexton [mailto:georges@mhsoftware.com]
>>> Subject: Re: Rendering JSP files through Apache
>>> My reading of it says that any request that matches a known context path
>>> must be routed to the web application. It seems pretty cut and dried
>>> to me.
>> That's true only when the request is processed by the servlet
>> container.  If the request is handled elsewhere, clearly the servlet
>> spec clause doesn't apply.
>
> The problem is then that as a system, the container isn't compliant.

No, it's the *system* that is broken.  The container itself is doing 
exactly what it is being told to do.  If you're not telling it to do the 
correct things, that's on you, not on the container.


> What you're in essence saying is that the compliance of the "system"
> isn't a concern. My belief is that "as a system", the end result has to
> be compliant because my application is deployed "on a system". If the
> system breaks the application, then it's not compliant.
>
> I suppose it's like eating an apple. At what point does the apple become
> you?

Once it's inside you, when your body can start processing it.  Just like 
the request must get inside the container for it to be processed IAW the 
spec.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: Rendering JSP files through Apache

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: George Sexton [mailto:georges@mhsoftware.com] 
> Subject: Re: Rendering JSP files through Apache

> The problem is then that as a system, the container isn't compliant. 
> What you're in essence saying is that the compliance of the "system" 
> isn't a concern. My belief is that "as a system", the end result has to 
> be compliant because my application is deployed "on a system". If the 
> system breaks the application, then it's not compliant.

I think you're way, way off base.  The servlet spec does not, in any way, attempt to define the semantics of a "system"; it is explicitly confined to the actions of a servlet container.  If a system administrator chooses to deploy multiple components within a system, it's up to that admin, not the servlet spec, to decide which components are involved in any given flow.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Rendering JSP files through Apache

Posted by George Sexton <ge...@mhsoftware.com>.

On 4/9/2015 12:58 PM, Caldarale, Charles R wrote:
>> From: George Sexton [mailto:georges@mhsoftware.com]
>> Subject: Re: Rendering JSP files through Apache
>> My reading of it says that any request that matches a known context path
>> must be routed to the web application. It seems pretty cut and dried to me.
> That's true only when the request is processed by the servlet container.  If the request is handled elsewhere, clearly the servlet spec clause doesn't apply.

The problem is then that as a system, the container isn't compliant. 
What you're in essence saying is that the compliance of the "system" 
isn't a concern. My belief is that "as a system", the end result has to 
be compliant because my application is deployed "on a system". If the 
system breaks the application, then it's not compliant.

I suppose it's like eating an apple. At what point does the apple become 
you?



>
>   - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>

-- 
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com

RE: Rendering JSP files through Apache

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: George Sexton [mailto:georges@mhsoftware.com] 
> Subject: Re: Rendering JSP files through Apache

> My reading of it says that any request that matches a known context path 
> must be routed to the web application. It seems pretty cut and dried to me.

That's true only when the request is processed by the servlet container.  If the request is handled elsewhere, clearly the servlet spec clause doesn't apply.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Rendering JSP files through Apache

Posted by Mark Thomas <ma...@apache.org>.
On 09/04/2015 19:50, George Sexton wrote:
> Chris
> 
> On 4/9/2015 10:06 AM, Christopher Schultz wrote:
>> Just my two cents, but any server that works the way you want is
>> not compliant with the servlet specification. It states that all
>> requests for a context must be passed to the container.
>> ??
>>
>> The servlet spec doesn't apply to environments, only containers. If
>> the OP wants to have Apache httpd serve static files and proxy dynamic
>> requests, that's perfectly reasonable.
> 
> Quoting Servlet Specification 3.0, section 4.1 Servlet context, it says:
> 
> /A ServletContext is rooted at a known path within a Web server. For
> example, a servlet context could be located at
> http://www.mycorp.com/catalog. All requests that begin with the /catalog
> request path, known as the context path, are routed to the Web
> application associated with the ServletContext.//
> /
> My reading of it says that any request that matches a known context path
> must be routed to the web application. It seems pretty cut and dried to me.
> 
> Can you help me understand why that's not the case?

It only applies to requests that reach the WebContainer (in this case
Tomcat). What happens before that in terms of reverse proxies is out of
scope for the Servlet spec.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Rendering JSP files through Apache

Posted by George Sexton <ge...@mhsoftware.com>.
Chris

On 4/9/2015 10:06 AM, Christopher Schultz wrote:
> Just my two cents, but any server that works the way you want is
> not compliant with the servlet specification. It states that all
> requests for a context must be passed to the container.
> ??
>
> The servlet spec doesn't apply to environments, only containers. If
> the OP wants to have Apache httpd serve static files and proxy dynamic
> requests, that's perfectly reasonable.

Quoting Servlet Specification 3.0, section 4.1 Servlet context, it says:

/A ServletContext is rooted at a known path within a Web server. For 
example, a servlet context could be located at 
http://www.mycorp.com/catalog. All requests that begin with the /catalog 
request path, known as the context path, are routed to the Web 
application associated with the ServletContext.//
/
My reading of it says that any request that matches a known context path 
must be routed to the web application. It seems pretty cut and dried to me.

Can you help me understand why that's not the case?


>
> It's also easy to do.
>
>> What you're suggesting is what GoDaddy does. The problem is that if
>> you map requests for things like css, javascript, or even ".html"
>> pages to a servlet, then it breaks.
>>
>> Bad idea.
> ?
>
> Why would a servlet have a problem handling a request for a .html
> file? The DefaultServlet was designed with that explicit purpose in mind
> .
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJVJqOHAAoJEBzwKT+lPKRYL6cQAKELJ476ux4/+UM1KcLMSWtR
> hh1Ft/uiU9vS2dhTvLZuRNCdzBHNL61Xq599CfHmFgBiKke68bEej9mjWaa8QqLc
> lHi2uEzO8OtXvR0OO/6hTtF3H1bxGh0OFE51BZ7J6mBXzZxzxmpee8HKs5EfrPpR
> PnbETVAJzzBOpduW6/m4UKNflcna5Cm0CATQVHyrKAm1PX3/3s3o0jF82PITW8ad
> dRBSt3IxxhjiOjvB119CGAyx3OlxqRCpvDZXerjhKP7lFxKN1VpbaaR27CRnM+RX
> /OPMUI0Mj8dVjnYZSc92lFbVRykYJf7ItTMpVQEYYG992gGKWRRwhPXVxDyUpMzq
> r0W6rCs3NV20OjUTS3peYACdDNzp8Etk2TT3T9SfowXv+6DUbIyDrBD/sHXrHw3l
> NAaraRIQzsUjvRITYIdK2np4EBHsnwZBP7Do5YjJclYDq4QUsnjfLDD/Y3jfpNs8
> +zVJa9lNaJktKPCzN5hy1mMc+cKLZd2Z+wa58+YkiCAr4uffBAqMZ8bOCoWdSqa5
> bowJ1/XT4DI13Ji36AliiVJIUcEk2pYy58kqD1c/12asO5BgETI4BdGfT9AI3bBE
> qcJPkNH5VKb9G6+It2LJvGEpZhxCr2vZRVluTlUcymgFtNu5KZAhO4OAn4p5Ch78
> LDSuJI5jc5NsbeMHFLMS
> =Fb2W
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>

-- 
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com

Re: Rendering JSP files through Apache

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

George,

On 4/9/15 10:52 AM, George Sexton wrote:
> On 4/8/2015 6:15 PM, Leggio, Andrew wrote:
>> This contains both HTML and JSP.  I would like the HTML to be
>> handled through Apache and JSP pages to be handled by TOMCAT.
>> How do I accomplish this?
> 
> Just my two cents, but any server that works the way you want is
> not compliant with the servlet specification. It states that all
> requests for a context must be passed to the container.

??

The servlet spec doesn't apply to environments, only containers. If
the OP wants to have Apache httpd serve static files and proxy dynamic
requests, that's perfectly reasonable.

It's also easy to do.

> What you're suggesting is what GoDaddy does. The problem is that if
> you map requests for things like css, javascript, or even ".html"
> pages to a servlet, then it breaks.
> 
> Bad idea.

?

Why would a servlet have a problem handling a request for a .html
file? The DefaultServlet was designed with that explicit purpose in mind
.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVJqOHAAoJEBzwKT+lPKRYL6cQAKELJ476ux4/+UM1KcLMSWtR
hh1Ft/uiU9vS2dhTvLZuRNCdzBHNL61Xq599CfHmFgBiKke68bEej9mjWaa8QqLc
lHi2uEzO8OtXvR0OO/6hTtF3H1bxGh0OFE51BZ7J6mBXzZxzxmpee8HKs5EfrPpR
PnbETVAJzzBOpduW6/m4UKNflcna5Cm0CATQVHyrKAm1PX3/3s3o0jF82PITW8ad
dRBSt3IxxhjiOjvB119CGAyx3OlxqRCpvDZXerjhKP7lFxKN1VpbaaR27CRnM+RX
/OPMUI0Mj8dVjnYZSc92lFbVRykYJf7ItTMpVQEYYG992gGKWRRwhPXVxDyUpMzq
r0W6rCs3NV20OjUTS3peYACdDNzp8Etk2TT3T9SfowXv+6DUbIyDrBD/sHXrHw3l
NAaraRIQzsUjvRITYIdK2np4EBHsnwZBP7Do5YjJclYDq4QUsnjfLDD/Y3jfpNs8
+zVJa9lNaJktKPCzN5hy1mMc+cKLZd2Z+wa58+YkiCAr4uffBAqMZ8bOCoWdSqa5
bowJ1/XT4DI13Ji36AliiVJIUcEk2pYy58kqD1c/12asO5BgETI4BdGfT9AI3bBE
qcJPkNH5VKb9G6+It2LJvGEpZhxCr2vZRVluTlUcymgFtNu5KZAhO4OAn4p5Ch78
LDSuJI5jc5NsbeMHFLMS
=Fb2W
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Rendering JSP files through Apache

Posted by George Sexton <ge...@mhsoftware.com>.

On 4/8/2015 6:15 PM, Leggio, Andrew wrote:
> This contains both HTML and JSP.  I would like the HTML to be handled through Apache and JSP pages to be handled by TOMCAT.  How do I accomplish this?

Just my two cents, but any server that works the way you want is not 
compliant with the servlet specification. It states that all requests 
for a context must be passed to the container.

What you're suggesting is what GoDaddy does. The problem is that if you 
map requests for things like css, javascript, or even ".html" pages to a 
servlet, then it breaks.

Bad idea.

>
> This is a Linux environment with Apache version 2.4.6 and Tomcat version 7.
>
> Thanks....
>
> Andrew J. Leggio | MBIA Services Corporation | Assistant Vice President | Phone P (914) 765-3206 | Fax ( (914) 765-3095 |   Andrew.Leggio@mbia.com
>
>
> -----Original Message-----
> From: André Warnier [mailto:aw@ice-sa.com]
> Sent: Wednesday, April 08, 2015 5:34 PM
> To: Tomcat Users List
> Subject: Re: Rendering JSP files through Apache
>
> Leggio, Andrew wrote:
>> I have the following being used in my conf file:
>>
>> <IfModule mod_proxy_ajp.so>
>>    ProxyPass / ajp://localhost:8009/
>> </IfModule>
>>
>> Does this actually direct jsp files to use Tomcat?
>>
> That is a funny way of putting it.
> What the above does - if everything else is installed and configured correctly - is proxying *all* HTTP requests originally directed to Apache httpd (including requests for any JSP page), toward a Tomcat supposedly running on the same host, and supposedly listening on port 8009.
> Now whether this is actually what is happening or not, is anyone's guess so far.
> Chances are that this is not happening though, since otherwise you probably would not be asking what's wrong.
>
> The question is also : if you are going to proxy all requests from Apache httpd to Tomcat anyway, then why do you think that you need Apache httpd ?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ------------------------------------------------------------------------------
> This e-mail, including any attachments, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information.  If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of any part of this e-mail is strictly prohibited; please contact the sender and permanently delete the original and any copies of it.
> ------------------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>

-- 
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com

RE: Rendering JSP files through Apache

Posted by "Leggio, Andrew" <An...@mbia.com>.
This contains both HTML and JSP.  I would like the HTML to be handled through Apache and JSP pages to be handled by TOMCAT.  How do I accomplish this?

This is a Linux environment with Apache version 2.4.6 and Tomcat version 7.

Thanks....

Andrew J. Leggio | MBIA Services Corporation | Assistant Vice President | Phone P (914) 765-3206 | Fax ( (914) 765-3095 |   Andrew.Leggio@mbia.com


-----Original Message-----
From: André Warnier [mailto:aw@ice-sa.com] 
Sent: Wednesday, April 08, 2015 5:34 PM
To: Tomcat Users List
Subject: Re: Rendering JSP files through Apache

Leggio, Andrew wrote:
> I have the following being used in my conf file:
> 
> <IfModule mod_proxy_ajp.so>
>   ProxyPass / ajp://localhost:8009/
> </IfModule>
> 
> Does this actually direct jsp files to use Tomcat?
> 

That is a funny way of putting it.
What the above does - if everything else is installed and configured correctly - is proxying *all* HTTP requests originally directed to Apache httpd (including requests for any JSP page), toward a Tomcat supposedly running on the same host, and supposedly listening on port 8009.
Now whether this is actually what is happening or not, is anyone's guess so far.
Chances are that this is not happening though, since otherwise you probably would not be asking what's wrong.

The question is also : if you are going to proxy all requests from Apache httpd to Tomcat anyway, then why do you think that you need Apache httpd ?


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org



------------------------------------------------------------------------------
This e-mail, including any attachments, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information.  If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of any part of this e-mail is strictly prohibited; please contact the sender and permanently delete the original and any copies of it.
------------------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Rendering JSP files through Apache

Posted by André Warnier <aw...@ice-sa.com>.
Leggio, Andrew wrote:
> I have the following being used in my conf file:
> 
> <IfModule mod_proxy_ajp.so>
>   ProxyPass / ajp://localhost:8009/
> </IfModule>
> 
> Does this actually direct jsp files to use Tomcat?
> 

That is a funny way of putting it.
What the above does - if everything else is installed and configured correctly - is 
proxying *all* HTTP requests originally directed to Apache httpd (including requests for 
any JSP page), toward a Tomcat supposedly running on the same host, and supposedly 
listening on port 8009.
Now whether this is actually what is happening or not, is anyone's guess so far.
Chances are that this is not happening though, since otherwise you probably would not be 
asking what's wrong.

The question is also : if you are going to proxy all requests from Apache httpd to Tomcat 
anyway, then why do you think that you need Apache httpd ?


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org