On Fri, 13 Jun 1997, Ira Abramov wrote:
> On Thu, 12 Jun 1997, Brian Behlendorf wrote:
>
> > The release of 1.2.0 caused an unprecedented amount of traffic on our
> > site; so much so that the bandwidth provider for www.apache.org has
> > begun to grumble. To address this, we have taken some measures to bolster
> > the effectiveness of the site in supporting mirrors:
>
> why am I not surprised? ;)
>
> If netscape can do it, so can we... I think the load on apache's central
> site means that it shouldn't even be linked as a download site, (smart
> users will go directly to the FTP, but web surfers will never be turned
> directly to ftp://www.apache.org).
Heh - bandwidth has calmed down quite a bit since we've made the
changes, but this is something we'll consider.
> > 1) We will now be running CGI scripts on mirror sites. Previously all CGI
> > scripts, such as the search field and bug database, had an explicit link
> > back to www.apache.org. These CGI scripts only rely upon perl 4 (or 5)
> > being at "/usr/local/bin/perl". Is this a problem?
>
> I imagine every perl installation around has either the binary or a link
> there, to support the many scripts out there.
One other thing this has brought up - apparently some mirrors are not
preserving file permissions, so some of the CGI's are apprently not
executable. In addition, the "index.cgi" in the /mirrors/ directory
is not being executed. Looks like we have two more dependencies:
.cgi being able to run anywhere
DirectoryIndex index
Options Multiviews turned on.
Eek. This fancy mirror strategy is looking to be a boondoggle. What
do you all think?
> > 2) Sites which pull down their content via ProxyPass will not have
> > dynamically generated mirror pages, though they should be cacheable.
>
> I hope I'm not out of my line here: is this method at all realistic for
> this use? sounds to me like a cool way to mirror joe's page of jokes, not
> a busy site such as Apache is.
Not out of line at all. In theory, this should be a very slick
> > There may be more issues brought up by this than I anticipated - let's
>
> first: where are the CGI's going to sit permanently? if there is a cgi-bin
> dir, we should make sure there is a ScriptAlias for it, otherwise make
> *.cgi executable in the apache dir (default for me, but not for some).
Right. I am so used to sprinkling .cgi's throughout the site, I
didn't even think about that. I had abolished /cgi-bin/ long ago :)
The problem is that if we do that, everyone will have a different
/cgi-bin/ directory they'll have to configure, since many people have
their apache mirror a few directory levels down. That will make
several things difficult.
> maybe make sure through a .htaccess to cover at least SOME of the holes.
> (assuming it's allowed to override)
Hmm, maybe if we put a .htaccess in the apache directory with these
directives, things would be a lot smoother. How many out there use
.htaccess?
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
[EMAIL PROTECTED] www.apache.org hyperreal.com http://www.organic.com/JOBS
