Thanks for the hint, I've read the spec many times.


I'm not clear what you are saying. Its two requests, whether its Apache + Tomcat, Apache alone, or Tomcat alone. Check your access logs...you don't see one log entry for a HTML page with one image, you see two: a 200 for the HTML page, and a 200 for the image. Whether that HTML page is a static page, or the output from JSP, ASP, servlet, perl script, or anything else.

Your statement was "No, there is only one request that is sent from browser to Apache. Apache will reroute the request to Tomcat as needed."

This is false, unless you are speaking only to the request for the JSP. Apache will receive one request for the JSP/servlet, which will be routed to Tomcat. If the HTML output of the JSP/servlet includes an IMG tag, then Apache will receive a second request for the image. 1 + 1 = 2.

John

Nguyen Anh Tuan wrote:

Hi, John,
Lets say you have one static HTML page with one image
in it. You can serve it with Apache stand alone (or
any stand alone Web server). So howmany requests are
there ?

Do you count : HTML : 1 request
Image : 1 request 1+1=2 requests


The answer is : You just request for a page, and
whatever in it will be sent back along with the page.
Please look into the RFC document of HTTP and HTTPS
protocol to see how a request is handled.

With a combination of Apache/Tomcat: The fact is : Every HTTP/HTTPS request is sent to Apache Webserver.
If there is a request to JSP/Servlet, it will be
rerouted from Apache to Tomcat (this is done on the
server, nothing concerned to browser), then when the
HTML page is created from JSP/Servlet in Tomcat, it is
sent back to Apache, then Apache sends the HTML page
back to the browser.


So the user sees only a scenario like this:
Request sent to Apache.
Whatever request it is, receive back a HTML page.

Thus, the amount of requests for one JSP/Servlet with
image sent to Apache/Tomcat = Exactly the amount of
requests for one static HTML page with images sent to
a stand alone Apache (or whatever stand alone
Webserver).

Of course, time will be needed to send requests from
Apache to Tomcat and for Tomcat to generate HTML from
JSP/Servlet and send it back to Apache. However, this
is done on the server and has nothing to do with
browser.

It depends on how you organize the site. If the site contains mix data (many static HTML pages
and JSP/Servlet), you should use a combination
Apache/Tomcat, because Apache handles static HTML
pages must faster than Tomcat does.


However, if you have only JSP/Servlet, Tomcat stand
alone is fine, because you have no use of Apache,
except rerouting JSP/Servlet to Tomcat. It is a waste
of time, because you can send JSP/Servlet requests
directly to Tomcat if you use Tomcat stand alone.



--- John Turner <[EMAIL PROTECTED]> wrote:

servelet = one request

image = one request

1 + 1 = 2 requests

John

Nguyen Anh Tuan wrote:


No, there is only one request that is sent from
browser to Apache. Apache will reroute the request

to


Tomcat as needed.
So what you are using now is the best

configuration.


--- [EMAIL PROTECTED] wrote:


I am working on a servlet that will be served from
tomcat which is
connected to apache. Currently I have the servlet
being handled by
tomcat, and the image handled by apache.
Won't this require 2 get requests by the browser? One being the image,
and one being the servlet?
Unfortunately, this is an SSL protected site and
none of the pages are
cached. So my question is, what is the best
approach with performance in
mind? What is the fasted way to get the image and
dynamic HTML back to
the browser ?




---------------------------------------------------------------------

To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]




__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

---------------------------------------------------------------------
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]



Reply via email to