|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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.comit 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.
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.
[Older Fedora Users Mail] [Home] [Fedora Legacy] [Fedora Desktop] [iPod Nano] [ATA RAID] [Fedora Bible] [Fedora Marketing] [Fedora Mentors] [Fedora Packaging] [Fedora SELinux] [Big List of Linux Books] [Yosemite News] [Yosemite Photos] [KDE Users] [Fedora Tools] [Fedora Docs]