Re: webapp- who handles static content: Tomcat or Apache (* OFF TOPIC *)

[Arshad Mahmood <ar...@compuvision.co.uk>]

Interesting idea to split the static content onto a different server.

Does anyone know how a browser like IE handles this kind of situation, I
know that with HTTP 1.1 the server will leave the connection open for
further requests so that images/styles, etc should be able to go through the
same connection as the original call.

Will IE open a single connection to "images.foo.com" to retrieve all the
images on a page, or will it open a new connection per image.

What happens with an SSL based page, will I get annoying messages because I
am getting insecure content. I assume I will have to put an SSL certificate
on the image server as well.

Regards.

----- Original Message -----
From: "Pier Fumagalli" <pi...@betaversion.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, July 11, 2002 2:00 AM
Subject: Re: webapp- who handles static content: Tomcat or Apache


> Pier Fumagalli <pi...@betaversion.org> wrote:
>
> > Cute... You can have some... Visit your local tobacconist.
> > Anyhow, you'll see my reasoning when the article gets published. Few
other
> > folks having the same problems we do (very high loads + servlets) don't
have
> > the same problem as well.... It's actually way easier and "better" (in
terms
> > of what solutions it allows you to have), to move them away entirely
from
> > the web application at all...
> >
> > People doing GIFs HTMLs and CCS are (in our case), completely separate
from
> > JSP/Servlet writers, so I don't even need to give them acceess to the
web
> > application files... They can't overwrite or even "touch" any of the
dynamic
> > content...
>
> Finally the article (and together with it its full response) is up...
>
>     http://www.onjava.com/
>     http://www.onjava.com/pub/a/onjava/2002/07/17/web.html
>
> Page one, at the bottom.
>
>     Pier
>
> --
> [Perl] combines all the worst aspects of C and Lisp:  a billion of
different
> sublanguages in  one monolithic executable.  It combines the power of C
with
> the readability of PostScript. [Jamie Zawinski - DNA Lounge - San
Francisco]
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: webapp- who handles static content: Tomcat or Apache (* OFF TOPIC *)

[Pier Fumagalli <pi...@betaversion.org>]

"Arshad Mahmood" <ar...@compuvision.co.uk> wrote:

> Interesting idea to split the static content onto a different server.
> 
> Does anyone know how a browser like IE handles this kind of situation, I
> know that with HTTP 1.1 the server will leave the connection open for
> further requests so that images/styles, etc should be able to go through the
> same connection as the original call.
> 
> Will IE open a single connection to "images.foo.com" to retrieve all the
> images on a page, or will it open a new connection per image.
> 
> What happens with an SSL based page, will I get annoying messages because I
> am getting insecure content. I assume I will have to put an SSL certificate
> on the image server as well.

When using SSL, or if you want to use keepalive fully, the optimal thing to
do for "convenience" would be to do what we used to do @ VNU 5 months ago,
the application is somewhere, and images/static are under a certain path
(for instance in our case /v6_....) . The browser can reuse the connection,
and the server can use the same certificate for both...

The "problem" we're solving by splitting the servers is splitting the load
as well. As you might know, on our www server, when we separated out images
the load went from an average of 3.50 daily, to 1.50, and the images server
is just an very very basic and skinny HTTPd 2.0 with Worker... Far less
heavy than the full web server on the main www... :)

    Pier


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>