|
Home > Archive > WebSphere Edge Server > December 2004 > Serving static content with WAS (and Caching Proxy) or IHS?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Serving static content with WAS (and Caching Proxy) or IHS?
|
|
|
| WAS 5.0 and IHS. How do you guys split your static and dynamic content on
the same machine? Do you let WAS always serve up images,css,etc.? Do you
point IHS at the WAS "deploy" directory? If so, what method do you use to
prevent IHS from being able to serve up dynamic content (like JPSs)
directly? Or do you deploy static content outside of WAS and outside of the
WAR/EAR file?
I've also been wondering if it's even worth using IHS at all if you're
fronting the whole thing with a Caching Proxy anyway. But I've found no
good advice on this whole issue.
The RedBooks and manuals all say to use a Web Server for production
situations, but I can only see this being useful if WAS is not going to be
serving up your static content. Otherwise, what does IHS gain you? (The
internal HTTP server is IHS too, right? I mean, it reports itself as IHS
1.3.12, I think.)
Thanks for any advice/thoughts,
Doug
| |
|
| Interesting considerations. I hope others will comment as well.
quote:
> How do you guys split your static and dynamic content on
> the same machine?
Basically, we don't (details follow :-).
quote:
> Do you let WAS always serve up images, css,etc.?
Never.
quote:
> Do you point IHS at the WAS "deploy" directory?
Yes, we add an Alias to point to the .war directory.
quote:
> If so, what method do you use to
> prevent IHS from being able to serve up dynamic content
WebSphere plugin has it (parly) built-in. IHS plug-in config file contains
the list of URIs that are to be addressed to WebSphere instead of being
served directly (the exhaustive list of servlets + *.jsp). So, it will never
give the JSP sources (although there was a fix recently published :-), but
anyway, JSPs do not contain sensible data when you develop the MVC way and
use taglib's). Additionaly, we have a directive in httpd.conf to explicitely
forbid HTTP access to the WEB-INF directory.
quote:
> Or do you deploy static content outside of WAS and outside of the
> WAR/EAR file?
Up to now, I don't have good reasons to do so, as it requires additional
work (or scripting) and I don't see the benefit.
quote:
> I've also been wondering if it's even worth using IHS at all if you're
> fronting the whole thing with a Caching Proxy anyway.
You got a point here, I think.
We don't use CP. We're playing on cache-control and content expiration. IHS
is not only usefull for caching, but also for security (restrict access
based on IPs, etc but maybe CP does it as well). My point is simply that
anything you'd be willing to do with an actual HTTP server cannot be done by
WebSphere built-in HTTP server, AFAIK. For example, we generate cookies
automatically thanks to IHS (but maybe CP can do this as well). Also, from
the performance point-of-view, I'm willing to believe that IHS does the job
better than WAS HTTP server to server static content (although I have no
proof of this, I admit).
quote:
> use a Web Server for production
> situations, but I can only see this being useful if WAS is not going to be
> serving up your static content.
IHS plug-in also has load-balancing features (elementary features as
compared with actual load-balancers, but usefull when cloning).
quote:
> The internal HTTP server is IHS too, right?
Not at all. But wait... Are we speaking of the same things after all ?
To me WAS built-in HTTP server (aka 'embedded HTTP server') is nothing but a
regular servlet that you activate/deactivate via ibm-web-ext.xmi
(fileServingEnabled attribute).
IHS, in contrast, is a separate product. But it gets seemlessly integrated
with WebSphere, thanks to a plug-in .dll or .so, that is declared in the
httpd.conf of IHS (or installed as an ISAPI filter in IIS).
Do you agree on this ?
quote:
> I mean, it reports itself as IHS 1.3.12
Yes, because all requests are going through IHS and it adds its signature
automatically (and you can only partly prevent this). So, all HTTP responses
contains IHS signature.
Ben.
| |
|
| Thanks for the thoughts. A few replies/comments:
"Ben_" <reply@newsgroup.com> wrote in message
news:bl1oio$7poa$1@news.boulder.ibm.com...
quote:
> Yes, we add an Alias to point to the .war directory.
>
> WebSphere plugin has it (parly) built-in. IHS plug-in config file contains
> the list of URIs that are to be addressed to WebSphere instead of being
> served directly (the exhaustive list of servlets + *.jsp). So, it will
neverquote:
> give the JSP sources (although there was a fix recently published :-), but
> anyway, JSPs do not contain sensible data when you develop the MVC way and
> use taglib's). Additionaly, we have a directive in httpd.conf to
explicitelyquote:
> forbid HTTP access to the WEB-INF directory.
Ok. Interesting. That would definitely prevent the security issue I was
concerned with. However, our JSPs and stuff (tiles) aren't under WEB-INF.
They're actually under the top-level of the WAR file. Wonder if we need to
change that or what is standard practice. Admittedly we're new to the
recent J2EE deployment standards (having been on WAS 3.5 for a few years).
quote:
> You got a point here, I think.
> We don't use CP. We're playing on cache-control and content expiration.
IHSquote:
> is not only usefull for caching, but also for security (restrict access
> based on IPs, etc but maybe CP does it as well). My point is simply that
> anything you'd be willing to do with an actual HTTP server cannot be done
byquote:
> WebSphere built-in HTTP server, AFAIK. For example, we generate cookies
> automatically thanks to IHS (but maybe CP can do this as well).
I'm curious - what kinds of cookies do you generate other than the session
ones that WAS generates?
quote:
> IHS plug-in also has load-balancing features (elementary features as
> compared with actual load-balancers, but usefull when cloning).
Good point. Since we're unlikely to use vertical cloning, and we'd normally
prefer local IHS to dispatch to local WAS, maybe this isn't too useful for
us?
quote:
> Not at all. But wait... Are we speaking of the same things after all ?
> To me WAS built-in HTTP server (aka 'embedded HTTP server') is nothing but
aquote:
> regular servlet that you activate/deactivate via ibm-web-ext.xmi
> (fileServingEnabled attribute).
> IHS, in contrast, is a separate product. But it gets seemlessly integrated
> with WebSphere, thanks to a plug-in .dll or .so, that is declared in the
> httpd.conf of IHS (or installed as an ISAPI filter in IIS).
> Do you agree on this ?
I agree. I'm just saying that the "embedded HTTP server" reports itself
*also* as IHS. See below:
quote:
> Yes, because all requests are going through IHS and it adds its signature
> automatically (and you can only partly prevent this). So, all HTTP
responsesquote:
> contains IHS signature.
IHS on the WAS box, if I connect to port 80, reports itself as IHS 1.3.*26*.
If I connect directly to the Web Container transport on port 9080, it
reports itself as IHS 1.3.*12*. I thought this was interesting and
surprising. Hence the question.
Thanks again for your ideas!
Doug
| |
|
| > > > Do you point IHS at the WAS "deploy" directory?quote:
>
> Ok. Interesting. That would definitely prevent the security issue I was
> concerned with. However, our JSPs and stuff (tiles) aren't under WEB-INF.
> They're actually under the top-level of the WAR file. Wonder if we need
toquote:
> change that or what is standard practice. Admittedly we're new to the
> recent J2EE deployment standards (having been on WAS 3.5 for a few years).
By the way, I've also considered making an explicit static-content
subdirectory in the WAR file and pointing the IHS DocumentRoot directly
there. Like, maybe, /htdocs.
| |
|
| > However, our JSPs and stuff (tiles) aren't under WEB-INF.
So do we. It's safe because the plug-in will "catch" the request and forward
it WebSphere, just because the plug-in's config file will contain an
explicit entry for "*.jsp". So wherever the JSPs are, they will be handled
by WebSphere.
quote:
> I'm curious - what kinds of cookies do you generate other than the session
> ones that WAS generates?
We use IBM Network Dispatcher's passive cookie affinity for session affinity
(IBM ND is a software load-balancer). This mechanism relyes on the back-end
web container (be it IHS or WebSphere) to have a cookie with a unique entry
to identify itself. Some people just use the fact that jsessionid contains
the clone id (after the semi-colon), but we prefered to use a dedicated
cookie. So we make IHS generate a cookie automatically.
One could also use it for user-tracking, etc.
quote:
> we'd normally
> prefer local IHS to dispatch to local WAS, maybe this isn't too useful for
> us?
We don't use vertical cloning either (but we are considering it, because
huge JVMs are not a good thing, so we may want to split the application into
two clones). Anyway, I mentionned it for completeness.
quote:
>the Web Container transport on port 9080, it
> reports itself as IHS 1.3.*12*.
Interesting. I'd not been curious enough yet to look at this. I've always
been thinking that IHS forced the signature, but I must be wrong then... :-)
| |
|
| > They're actually under the top-level of the WAR file. Wonder if we needquote:
> to change that or what is standard practice.
I *think* the standard is to place JSPs under WEB-INF.
quote:
> By the way, I've also considered making an explicit static-content
> subdirectory in the WAR file and pointing the IHS DocumentRoot directly
> there.
I don't the point and the benefit you expect.
| |
|
| "Ben_" <reply@newsgroup.com> wrote in message
news:bl43au$2i3m$2@news.boulder.ibm.com...quote:
> I *think* the standard is to place JSPs under WEB-INF.
I was discussing this with some co-workers yesterday, and here's why that
doesn't *seem* right to us. My WAR is currently created with the JSPs not
under WEB-INF (which seemed the most natural organization utilizing the Ant
"War" task). So WAS deploys them at the top level of the .WAR directory.
They are served up with a URL of <hostname>/<context_root>/<page/path>.jsp.
If I deployed them under WEB-INF, I'd have to use a URL of
<hostname>/<context_root>/WEB-INF/<page/path>.jsp, right? i.e. I don't know
how to specify the WAS "DocumentRoot" in WAS 5.0 (it was easy in WAS3.5).
Is there a way?
quote:
> I don't the point and the benefit you expect.
It seemed to me that I had to physically separate the static and dynamic
content to be able to *easily* prevent IHS from being able to serve up the
dynamic stuff. I'll explain more in my reply to your other reply.
| |
|
|
"Ben_" <reply@newsgroup.com> wrote in message
news:bl43au$2i3m$1@news.boulder.ibm.com...quote:
> So do we. It's safe because the plug-in will "catch" the request and
forwardquote:
> it WebSphere, just because the plug-in's config file will contain an
> explicit entry for "*.jsp". So wherever the JSPs are, they will be handled
> by WebSphere.
Ok. Here's where I'd made an assumption that I forgot. We have the "File
Enabling Servlet" (or whatever it's called now) enabled. Therefore,
anything under the Context Root will be handled by WebSphere. So... to have
static content served by IHS, it has to be accessed with a different URL
prefix. e.g. "/webapp/registration" vs. "/registration". For *that* to be
"secure", IHS can't have full access to all the WAS-served files. That led
me to physically separating the static and dynamic content as the easiest
mechanism for controlling this.
It used to be that the File servlet was required for URL-rewriting to work,
which we use, but I guess I don't know for sure that's still true. Seems
like the File servlet was also required for one or two other things we were
doing, but I won't swear it. I also thought enabling that servlet was the
default for WAS 5.0 deploys, but maybe not. Is it enabled for you?
quote:
session[QUOTE][color=darkred]
> We use IBM Network Dispatcher's passive cookie affinity for session
affinityquote:
> (IBM ND is a software load-balancer). This mechanism relyes on the
back-endquote:
> web container (be it IHS or WebSphere) to have a cookie with a unique
entryquote:
> to identify itself. Some people just use the fact that jsessionid contains
> the clone id (after the semi-colon), but we prefered to use a dedicated
> cookie. So we make IHS generate a cookie automatically.
> One could also use it for user-tracking, etc.
Interesting. We do run ND, in front of Caching Proxy, in front of IHS/WAS
on the same box. I'll have to chew on this some as it sounds promising. We
have not used ND's CBR so far, partly because people used to say it had poor
performance.
quote:
for[QUOTE][color=darkred]
> We don't use vertical cloning either (but we are considering it, because
> huge JVMs are not a good thing, so we may want to split the application
intoquote:
> two clones). Anyway, I mentionned it for completeness.
That's cool. I was just thinking out loud.
Thanks again for sharing your experiences. They've been very helpful. I
hope some others will jump in and contribute ideas/opinions too! I'd still
love to hear if Caching Proxy obviates the reason to let IHS serve static
content at all.
Doug
| |
|
| > to havequote:
> static content served by IHS, it has to be accessed with a different URL
> prefix. e.g. "/webapp/registration" vs. "/registration".
Is this your experience, really ? I don't see the need to do so. We have
worked with applications with and without FileServing enabled, and it has no
impact on the URLs you have to use to access the application (and direct
access to WebSphere is not possible).
quote:
> For *that* to be
> "secure", IHS can't have full access to all the WAS-served files.
Don't forget that the plug-in run in IHS and has the priority on it. It
decides whether the request is to be served by IHS or WAS. It makes its
decision thanks to the plugin-cfg.xml file. If you didn't have a look at it
yet, have a look at the file and you will understand, I think. You'll see
there is an exhaustive list of URLs that are declared to belong to WebSphere
(/snoop, /hello, /hitcount, *.jsp, etc). So, IHS won't serve that content
(even when WebSphere is down). I don't see any security exposure with this,
except that as told earlier we had to explicitely deny access to WEB-INF
directory (but it's a matter of a single line config in httpd.conf).
quote:
> It used to be that the File servlet was required for URL-rewriting to work
Really ? I can hardly comment on this, because we don't use URL-rewriting,
but I'd be quite surprised that URL-rewriting would require FileServing.
quote:
> Seems like the File servlet was also required for one or two other things
I know of people using it to give access to temporary javascripts, css,
images, etc created on disk under the document root of the application,
instead of keeping it in memory.
quote:
> I also thought enabling that servlet was the
> default for WAS 5.0 deploys, but maybe not. Is it enabled for you?
Yes it is, because FileServing is configured per webapp (ibm-web-ext.xmi
file in each WAR file in fact) and it is enabled by default when you build
WAR files with WSAD, because it is required for developers to run their app
within WSAD. We ask our build teams to disable to deploy on WAS.
quote:
> We have not used ND's CBR so far, partly because people used to say it had
poorquote:
> performance.
ND/CBR (more exactly Kernel Content Based Routing - KCBR) is indeed slower
than MAC forwarding, although it is claimed to be much faster than CP's CBR,
because it is "kernel" (but don't ask me what is meant exactly with kernel,
I don't know).
Just FYI, as a side-effect, in this mode, it works as a reverse proxy. So,
for the back-end HTTP server, the IP client is ND (it's the ND's IP you can
see in IHS logs, for example). But IMO, performance is not the issue,
because, usually, applications are the bottleneck, not the infrastructure (I
mean ND/KCBR can handle far much traffic than the back-ends).
Also, as regards WebSphere plug-in's load-balancing capabilities, I must add
for completeness, that it can do load-balancing locally as well as remote
(be it for clones on other (remote) nodes of the same Administrative domain
or when IHS is in DMZ and WAS is in the Trusted LAN).
| |
|
| "Ben_" <reply@newsgroup.com> wrote in message
news:bl4t8g$2tfi$1@news.boulder.ibm.com...quote:
> Is this your experience, really ? I don't see the need to do so. We have
> worked with applications with and without FileServing enabled, and it has
noquote:
> impact on the URLs you have to use to access the application (and direct
> access to WebSphere is not possible).
>
>
> Don't forget that the plug-in run in IHS and has the priority on it. It
> decides whether the request is to be served by IHS or WAS. It makes its
> decision thanks to the plugin-cfg.xml file. If you didn't have a look at
itquote:
> yet, have a look at the file and you will understand, I think. You'll see
> there is an exhaustive list of URLs that are declared to belong to
WebSpherequote:
> (/snoop, /hello, /hitcount, *.jsp, etc).
But there is no *.jsp in my pugin config file. There is just
<context-root>/*, I think because the File Serving servlet is enabled. So
every URL under the context-root will be served by WAS. That's what that
servlet is for - to cause WAS to handle files that don't have an explicit
mapping in plugin-cfg, right? If so, the only way to get IHS to serve up
something is to access it via some URL other than the context-root. I keep
thinking I'm missing some small step you're using, but I can't see it yet.
quote:
> So, IHS won't serve that content
> (even when WebSphere is down). I don't see any security exposure with
this,quote:
> except that as told earlier we had to explicitely deny access to WEB-INF
> directory (but it's a matter of a single line config in httpd.conf).
I'm still a little confused as to what you're doing. I thought I understood
it earlier, but I'm thinking now that I don't. Where is your IHS
DocumentRoot pointing? Where are your JSPs? Where are your static files?
quote:
work[QUOTE][color=darkred]
> Really ? I can hardly comment on this, because we don't use URL-rewriting,
> but I'd be quite surprised that URL-rewriting would require FileServing.
Again, it is definitely required under 3.5. I don't know about 4.0 and 5.0,
but I was assuming this was still true.
Doug
| |
|
| > But there is no *.jsp in my pugin config file. There is justquote:
> <context-root>/*, I think because the File Serving servlet is enabled.
What file are you referring to ? I think you're referring to
application.xml, but I'm referring to plugin-cfg.xml (to be found in
WebSphere/AppServer/config).
If you have some samples installed, you may already see that not all webapps
have a single entry, but instead have an exhaustive list of servlet URIs and
an entry for JSPs.
If you have no samples and want to see the difference, disable fileserving
in the war file and regen the plug-in (you can modify the ibm-web-ext.xmi
file directly on the file system, you needn't redeploy).
quote:
> I'm still a little confused as to what you're doing. I thought I
understoodquote:
> it earlier, but I'm thinking now that I don't. Where is your IHS
> DocumentRoot pointing? Where are your JSPs? Where are your static files?
I think the major difference between our two situtations is that we have a
dozen of applications running with their own URI, but you only have one
application with /* as URI. Can you confirm this ?
If this is your situation then I understand why you ask about DocumentRoot.
In fact we didn't change it, because we instead use one Alias directive per
application in httpd.conf. Anyway, you could still be able use our way of
working, by changing DocumentRoot to point to your .WAR file directory,
under /installedApps. But this is only usefull if you can get rid of
FileServing. If you can't, then I don't see a way to serve static content
with IHS and dynamic content with WAS with the same URI.
As regards, the JSP and static files, they are right under the root of the
WAR (or in sub-directories), not in WEB-INF, and we have an Alias (which has
the same URI as the app) for IHS to find them.
quote:
>
> Again, it is definitely required under 3.5.
Then, I'm suprised :-) and I learned something.
Hope I shed light.
Ben.
| |
|
| > > But there is no *.jsp in my pugin config file. There is justquote:
> What file are you referring to ? I think you're referring to
> application.xml, but I'm referring to plugin-cfg.xml (to be found in
> WebSphere/AppServer/config).
No. I'm referring to plugin-cfg.xml. That's my point about having the File
Serving servlet enabled.
quote:
> understood
files?[QUOTE][color=darkred]
> I think the major difference between our two situtations is that we have a
> dozen of applications running with their own URI, but you only have one
> application with /* as URI. Can you confirm this ?
I have many different applications as well. The ones that share a virtual
host have their own context-roots: /webapp/application1,
/webapp/application2, etc. We also, though, have some different apps that
use their own virtual hosts. Those use DocumentRoot. As you say, the
others just use Alias directives. I was trying to simplify the discussion
by talking only about the DocumentRoot ones.
quote:
> If this is your situation then I understand why you ask about
DocumentRoot.quote:
> In fact we didn't change it, because we instead use one Alias directive
perquote:
> application in httpd.conf. Anyway, you could still be able use our way of
> working, by changing DocumentRoot to point to your .WAR file directory,
> under /installedApps. But this is only usefull if you can get rid of
> FileServing. If you can't, then I don't see a way to serve static content
> with IHS and dynamic content with WAS with the same URI.
>
> As regards, the JSP and static files, they are right under the root of the
> WAR (or in sub-directories), not in WEB-INF, and we have an Alias (which
hasquote:
> the same URI as the app) for IHS to find them.
Ok. So this is what we do too. However, with the File Serving Servlet
enabled, that means you *have* to use different URL prefixes if you want IHS
to serve up any content at all. Otherwise, WAS handles it all. Then *that*
means you have to prevent IHS from getting to the other stuff in that common
directory.
Doug
| |
|
| > No. I'm referring to plugin-cfg.xml.
Are you very sure :-) ? Plugin-cfg.xml doesn't contain <context-root>
entries. But it rather looks like:
(snip)
<UriGroup Name="server1_Cluster_URIs">
<Uri Name="/snoop"/>
<Uri Name="/hello"/>
<Uri Name="/hitcount"/>
<Uri Name="*.jsp"/>
(snip)
The exact layout is described at
http://publib7b.boulder.ibm.com/was...un_plugin.html.
quote:
> However, with the File Serving Servlet
> enabled, that means you *have* to use different URL prefixes if you want
IHSquote:
> to serve up any content at all.
Yes, I think so.
So possible solutions:
* use LocationMatch directives with regular expressions to deny direct
access via IHS to JSP files and the WEB-INF directory (chances are low that
a servlet URI would match a resource IHS can find)
* deploy the static content in another location
* determine whatfor FileServing is really used and see if it can be replaced
by a file servlet of your own.
* determine if you really need to use FileServing and serve static content
with IHS (does it make much point when you have CP)
| |
|
| > > No. I'm referring to plugin-cfg.xml.quote:
> Are you very sure :-) ? Plugin-cfg.xml doesn't contain <context-root>
> entries. But it rather looks like:
> (snip)
> <UriGroup Name="server1_Cluster_URIs">
> <Uri Name="/snoop"/>
> <Uri Name="/hello"/>
> <Uri Name="/hitcount"/>
> <Uri Name="*.jsp"/>
> (snip)
>
> The exact layout is described at
> http://publib7b.boulder.ibm.com/was...un_plugin.html.
I'm very sure :-). I just called it context-root to point out that what's
in the <UriGroup> matches what I placed in the <context-root> in
Application.xml:
<UriGroup Name=" default_host_AZPortal_testapp01_Cluster_
URIs">
<Uri AffinityCookie="JSESSIONID"
AffinityURLIdentifier="jsessionid" Name="/PaymentServices/*"/>
<Uri AffinityCookie="JSESSIONID"
AffinityURLIdentifier="jsessionid" Name="/webapp/portal/*"/>
<Uri AffinityCookie="JSESSIONID"
AffinityURLIdentifier="jsessionid" Name="/webapp/admin/*"/>
<Uri AffinityCookie="JSESSIONID"
AffinityURLIdentifier="jsessionid" Name="/webapp/noi/*"/>
<Uri AffinityCookie="JSESSIONID"
AffinityURLIdentifier="jsessionid" Name="/webapp/ADEQAdmin/*"/>
<Uri AffinityCookie="JSESSIONID"
AffinityURLIdentifier="jsessionid" Name="/dlc/*"/>
</UriGroup>
quote:
> IHS
> Yes, I think so.
> So possible solutions:
> * use LocationMatch directives with regular expressions to deny direct
> access via IHS to JSP files and the WEB-INF directory (chances are low
thatquote:
> a servlet URI would match a resource IHS can find)
> * deploy the static content in another location
> * determine whatfor FileServing is really used and see if it can be
replacedquote:
> by a file servlet of your own.
> * determine if you really need to use FileServing and serve static content
> with IHS (does it make much point when you have CP)
Good summary. I agree those seem to be my options at this point. Hopefully
some other people will add opinions on those options :-)
Thanks again for your comments, Ben.
Doug
| |
| elfego 2004-09-17, 7:33 pm |
| Hi guys,
First of all, excuse me. English is not my native language.
I'm a WAS 5.0.2 user., and I'm reading this discussion.
Ben, you are right about the IHS knows how to handle the static and dynamic content, only disabling the "FileServing enabled" option in the war module.
But I think the WAS Webserver built-in is not a simple servlet. That's actually another Web Server"integrated" with WebSphere.
You can test this:
1. Shutdown the IHS (/usr/IBMHttpServer/bin/apachectl stop)
2. Try in your browser your.domain:9080/webapp/any_arch.jsp and you we'll see that your application keeps answering.
The reason is because although your IHS is down, Websphere is running his own WebServer (of course is an IHS-based one)
Now let me explain my case:
I have a webapp running with WAS5.0.2 and IHS as WEBServer. IHS is serving the static content and WAS is serving servlets and JSPs.
But I don't know exactly yet how virtual_host works with application server. I mean virtualhost is listening on port 80. HTTP transport on Application server (server1) is 9080. How or who makes these relationship (if it exist) ? The plug-in? (I don't see where it is) I don't know how explain it, but it works. Do you know that ?
Another question I have is:
I want to configure only a WAS AppServer in one machine and several webApps on several boxes. A webapp per box, of course each with an IHS, and IP and a domain name. Do you belive is that possible ? I think yes, but I don't know. May be I need to create a virtual_host per Webserver. Or may be several AppServers ?
TIA
Elfego | |
|
|
"elfego" <elfego.1cztvb@mail.webservertalk.com> wrote in message
news:elfego.1cztvb@mail.webservertalk.com...
>
> Hi guys,
> First of all, excuse me. English is not my native language.
> I'm a WAS 5.0.2 user., and I'm reading this discussion.
> Ben, you are right about the IHS knows how to handle the static and
> dynamic content, only disabling the "FileServing enabled" option in the
> war module.
> But I think the WAS Webserver built-in is not a simple servlet. That's
> actually another Web Server"integrated" with WebSphere.
> You can test this:
> 1. Shutdown the IHS (/usr/IBMHttpServer/bin/apachectl stop)
> 2. Try in your browser your.domain:9080/webapp/any_arch.jsp and you
> we'll see that your application keeps answering.
> The reason is because although your IHS is down, Websphere is running
> his own WebServer (of course is an IHS-based one)
I strongely believe that the embedded HTTP server is Java based and not
Apache/IHS based. One of the reason is that the WebSphere runtime
(WebSphere/AppServer directories) don't contain anything that looks like
Apache binaries or a subset of it. Another reason is that in WebSphere 3.5
this feature was actually a servlet like another and visible in the Admin
Console. I suppose over the course of time (in WebSphere 4.0) is has become
hidden but remains essentially Java code.
>
> Now let me explain my case:
> I have a webapp running with WAS5.0.2 and IHS as WEBServer. IHS is
> serving the static content and WAS is serving servlets and JSPs.
> But I don't know exactly yet how virtual_host works with application
> server. I mean virtualhost is listening on port 80. HTTP transport on
> Application server (server1) is 9080. How or who makes these
> relationship (if it exist) ? The plug-in? (I don't see where it is) I
> don't know how explain it, but it works. Do you know that ?
>
The internals of WebSphere are that the IBM HTTP server listens on port 80
and the web server plugin (a shared object or DLL) catches all requests. It
then looks at the WebSphere/AppServer/config/cell/plugin-cfg.xml file to
determine if the requested resource is to be served by WebSphere or not. If
so, it will search that file again to get the port of the embedded HTTP
server of the application (there is one per application server). This port
is defined in the Admin Console (in Web Container, HTTP Transport -- from
memory, I don't have a console at hand).
The file may look a bit messy, but I found that making the exercise of
trying to resolve the URI to host:port combination helped make things clear.
> Another question I have is:
> I want to configure only a WAS AppServer in one machine and several
> webApps on several boxes. A webapp per box, of course each with an IHS,
> and IP and a domain name. Do you belive is that possible ? I think yes,
> but I don't know. May be I need to create a virtual_host per
> Webserver. Or may be several AppServers ?
>
To me a webapp is an web application running in a J2EE web container. Thus
in WebSphere. You can't thus install a webapp on a separate box without
installing WebSphere there.
With WebSphere Network Deployment you can easily create multiple application
servers on the same physical host. If the machine has enough resource it's
not a problem. And all can be accessed via the port 80 (thanks to the
plugin, see above).
> TIA
>
> Elfego
>
>
>
> --
> elfego
HTH.
Ben.
| |
| elfego 2004-11-09, 5:55 pm |
| I strongely believe that the embedded HTTP server is Java based and not
Apache/IHS based. One of the reason is that the WebSphere runtime
(WebSphere/AppServer directories) don't contain anything that looks like
Apache binaries or a subset of it. Another reason is that in WebSphere 3.5
this feature was actually a servlet like another and visible in the Admin
Console. I suppose over the course of time (in WebSphere 4.0) is has become
hidden but remains essentially Java code.
Ok, I agree.
The internals of WebSphere are that the IBM HTTP server listens on port 80
and the web server plugin (a shared object or DLL) catches all requests. It
then looks at the WebSphere/AppServer/config/cell/plugin-cfg.xml file to
determine if the requested resource is to be served by WebSphere or not. If
so, it will search that file again to get the port of the embedded HTTP
server of the application (there is one per application server). This port
is defined in the Admin Console (in Web Container, HTTP Transport -- from
memory, I don't have a console at hand).
The file may look a bit messy, but I found that making the exercise of
trying to resolve the URI to host:port combination helped make things clear.
I'll take a further look about this. It makes sense.
To me a webapp is an web application running in a J2EE web container. Thus
in WebSphere. You can't thus install a webapp on a separate box without
installing WebSphere there.
With WebSphere Network Deployment you can easily create multiple application
servers on the same physical host. If the machine has enough resource it's
not a problem. And all can be accessed via the port 80 (thanks to the
plugin, see above).
I didn't mean to install a WebApp on each IHS box, but only a copy from WebApp.war folder from WAS box in order to have locally the static content. I can delete JSPs and .class files.
I'm doing it, but right now I'm having another problem with SSL because at the same time I want to migrate to IBMIHS 20.47.1
but it doesn't want to start with JKS file I configured for th IHS embedded.
I get this error:
[crit] SSL0104S: GSK could not initialize, Invalid password for keyfile.
Of course I created a .sth file but doesn't work.
If I create a new KDB keyfile it works very fine. I test with a trial cert.
So, I tried to import the cert from the JKS into the KDB file but I get this error:
An attempt to import the certificate has failed.
All the signer certificates must exist in the key database.
I checked, and exist all of the necessary signer certificates.
I'm stopped.
If someone knows a workaround help me please.
Ben, I let you know if I get it.
Thanks
elfego
PD. HTH = ??? (just curious) | |
|
| Hello,
There aren't many Google hits with this issue.
Is the following article of any help ?
http://groups.google.com/groups?hl=...398f8804&rnum=1
It also refers to some documentation.
HTH (Hope this help)
http://www.computeruser.com/resourc...es/nf.chat.html
"elfego" <elfego.1fhi1l@mail.webservertalk.com> wrote in message
news:elfego.1fhi1l@mail.webservertalk.com...
>
> I strongely believe that the embedded HTTP server is Java based and not
> Apache/IHS based. One of the reason is that the WebSphere runtime
> (WebSphere/AppServer directories) don't contain anything that looks
> like
> Apache binaries or a subset of it. Another reason is that in WebSphere
> 3.5
> this feature was actually a servlet like another and visible in the
> Admin
> Console. I suppose over the course of time (in WebSphere 4.0) is has
> become
> hidden but remains essentially Java code.
>
> Ok, I agree.
>
> The internals of WebSphere are that the IBM HTTP server listens on port
> 80
> and the web server plugin (a shared object or DLL) catches all
> requests. It
> then looks at the WebSphere/AppServer/config/cell/plugin-cfg.xml file
> to
> determine if the requested resource is to be served by WebSphere or
> not. If
> so, it will search that file again to get the port of the embedded
> HTTP
> server of the application (there is one per application server). This
> port
> is defined in the Admin Console (in Web Container, HTTP Transport --
> from
> memory, I don't have a console at hand).
> The file may look a bit messy, but I found that making the exercise of
> trying to resolve the URI to host:port combination helped make things
> clear.
>
> I'll take a further look about this. It makes sense.
>
>
> To me a webapp is an web application running in a J2EE web container.
> Thus
> in WebSphere. You can't thus install a webapp on a separate box
> without
> installing WebSphere there.
> With WebSphere Network Deployment you can easily create multiple
> application
> servers on the same physical host. If the machine has enough resource
> it's
> not a problem. And all can be accessed via the port 80 (thanks to the
> plugin, see above).
>
> I didn't mean to install a WebApp on each IHS box, but only a copy from
> WebApp.war folder from WAS box in order to have locally the static
> content. I can delete JSPs and .class files.
> I'm doing it, but right now I'm having another problem with SSL because
> at the same time I want to migrate to IBMIHS 20.47.1
> but it doesn't want to start with JKS file I configured for th IHS
> embedded.
> I get this error:
>
> [crit] SSL0104S: GSK could not initialize, Invalid password for
> keyfile.
>
> Of course I created a .sth file but doesn't work.
> If I create a new KDB keyfile it works very fine. I test with a trial
> cert.
> So, I tried to import the cert from the JKS into the KDB file but I get
> this error:
>
> An attempt to import the certificate has failed.
> All the signer certificates must exist in the key database.
>
> I checked, and exist all of the necessary signer certificates.
> I'm stopped.
>
> If someone knows a workaround help me please.
> Ben, I let you know if I get it.
> Thanks
>
> elfego
> PD. HTH = ??? (just curious)
>
>
>
> --
> elfego
> ------------------------------------------------------------------------
> Posted via http://www.webservertalk.com
> ------------------------------------------------------------------------
> View this thread: http://www.webservertalk.com/message53933.html
>
| |
| elfego 2004-12-03, 4:33 pm |
| Hello Ben_
Finally I got it.
The problem with the IHS was solved downloading the correct CA root, then importing the cert from JKS file
I already have a WAS box runnig an Application Server with 3 EARs, and serving to 3 Web Servers.
An WebServer for each EAR.
WAS is serving only tha dinamic content.
Each Webserver is serving in turn the static one. |
|
|
|
|