What is TUX? (Was Re: A heads up)

Indeed, I looked back through the archives and found some mention of the 
issue...it was before I subscribed to the list last September.  Since 
the search on the Redhat site appears to be broken for me, and I hadn't 
been a part of the previous discussions, I merely assumed.

As for nomenclature, TUX *is* a web server.  It is simply a 
static-content-only web server (I'll leave the userland modules out for 
the sake of this discussion).  If I type in the following:

  GET / HTTP/1.1
  Host: www.foo.com

it will return a perfectly valid web server response if there is a 
index.html file present in docroot.  If your web site is completely 
static, it can function without any outside assistance whatsoever.  If 
the resource isn't found and there is no backend server, TUX sends a 404 
all by itself.  This is in contrast to Squid where, in accelerator mode, 
if there is no backend web server, it cannot provide content.  Squid can 
be a true accelerator.  TUX, at worst, is a hybrid.  By this metric, TUX 
should be *expected* to serve all static content.  If it does not, it's 
raison d'etre is lost: there is no point to it.  The early versions of 
CERN did less than TUX (content ranges, content encoding, etc).  Does 
this mean that CERN was not a web server?

The deviation that you speak of includes "..", "?", and special file 
cases like PHP and JSP.  ".." is a potential security issue.  Dynamic 
content (commonly marked with "?") gets forwarded to another service.  
This is not fundamentally different from Apache opening a socket to an 
external Tomcat JVM process to serve a JSP file -- even if Tomcat is not 
configured to serve static files in the directory.

While its primary purpose may be to accelerate a userland web server, if 
its proxying/referral capabilities exclude it from the definition of 
"web server," Apache must be excluded as well since it can proxy/relay 
to another web server as well.  ;-)

TUX is indeed a web server: a web server optimized to accelerate access 
to static resources and redirect all other requests to an optional (but 
recommended) secondary web server.  I don't believe that I have 
misunderstood TUX...err...the Redhat Content Accelerator.  I am simply 
intent upon making it do something useful so that the load drops for 
userland -- the whole point to TUX in the first place.

Given) My textual content is dynamically generated with images, CSS, 
XSLT, Javascript, etc. as static resources.

Premise 1) The text content (HTML) will always be requested as the first 
browser request and is forwarded to the backend server which thereafter 
has total control of the socket.  (How would a browser know about an 
image if not for the <img> element?)
Premise 2) TUX misses >90% of the requests on my box if keepalives are 
enabled and the backend server can serve static files as well.
Premise 3) If TUX misses >90% of the requests because userland uses 
keepalives, TUX loses any real, measurable benefit -- TUX's advantage is 
lost in the content delivery noise.
Premise 4) If TUX serves all of the static content because the backend 
has keepalives disabled (or something similar), then it is as much a 
part of the content generation model as your backend server.
Premise 5) If it's a intregal part of the overall content generation 
model, configuring the backend to serve static resources is redundant 
and useless.
Conclusion 1) You must configure TUX to serve 100% of all static content 
(through disabling keepalives) or omit it from the chain as unnecessary 
processing overhead since almost everything bypasses it anyway.
Conclusion 2) TUX is *the* static web server or TUX is useless 
(especially if you have mostly dynamic content without regard to the 
number of static elements used in conjunction with the web page).

If the given changes to include static content, TUX becomes *even more 
important* to the content delivery model.  The only given where TUX 
becomes less important is with static content and dynamic images -- a 
very small niche.

See my point now?  You cannot just assert that it's just "a web 
accelerator" without completely disregarding it as an unnecessary 
variable in your web setup.

- Miles


Alex Kramarov wrote:

>the keepalive issues were discussed several times on the list, and you
>actually have a fundamental error in your regard to tux - tux is not a web
>server, it is a web accelerator. your backend server should be able to
>return static content, exactly as tux, since there will be requests for
>static content that tux will forward to the backend server, if the request
>diviates enough from the format tux expects. This was also discussed on the
>list.
>
>Regards,
>Alex.
>  
>