Re: UseCanonicalName Off *surprise*
On Fri, Dec 19, 2003 at 10:04:15AM -0600, William A. Rowe, Jr. wrote: > > UseCanonicalName Off, Host: header provided (HTTP/1.1) > > The host name header *excluding the host header port suffix * of the request > is concatenated to httpd 1.3's Port directive setting or the real port number > in httpd 2.0. The Port directive has some muddled ServerName/UseCanonicalName semantics which is what distinguishes it from the Listen directive. I think the behaviour you describe is intended. > Now this might appear to be a moot issue, but if a proxy that doesn't mangling > headers bounces requests from port 80 to another server's port 8080 attempting > to impersonate the front end proxy, everything should work, in theory, with > UseCanonicalName Off. As it turns out, UseCanonicalName must be turned > on to avoid the port :8080 suffix from being appended to the redirects. In this situation you should be using Listen rather than Port. Is 2.0 different? Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ SHETLAND ISLES: NORTHWEST 4, EASING VARIABLE 2. LATER INCREASING EAST THEN NORTHEAST 5 OR 6. MAINLY FAIR, ISOLATED SHOWERS. GOOD. MODERATE.
Re: Re: Advanced Mass Hosting Module
On Sat, Mar 15, 2003 at 11:14:44AM -0500, Nomentsoa-Tahiry Ramanampanoharana wrote: > > Instead of writing a new module from the scratch. I don't > know if it's a good idea to look at mod_rewrite RewriteMap > internal function first. I recommend against using mod_rewrite wherever possible. Yes it is essential in some situations, but frequently you will be better off with mod_alias and therefore much less hair. Everything that mod_vhost_alias does can be done with mod_rewrite, but enabling mod_rewrite and therefore letting customers use it is a scary prospect. With great power comes great responsibility, and users are far too frequently irresponsible. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ LOUGH FOYLE TO CARLINGFORD LOUGH: SOUTHEAST 5 OR 6, DECREASING 4 OR 5. FAIR. GOOD. MODERATE.
Re: Advanced Mass Hosting Module
> > Resending this to this list as I got no response on users list. Sorry, I missed the original version of this post. > > Currently, we are using flat config files generated by our website > > provisioning software to support our mass hosted customers. The reason > > for doing it this way, and not using the mod_vhost_alias module is > > because we need to be able to turn on/off CGI, PHP, Java, shtml etc on > > a per vhost basis. We need the power that having a distinct > > directive for each site gives you. > > > > Is there a better way? The mod_vhost_alias way came from a heritage of very basic web site provisioning, with little change in architecture since 1996. The model was abusing the filesystem as a database -- we were using permissions on users' home directories to record if they had been barred or had exceeded their quota. We also abused the DNS as a database, which is where UseCanonicalName DNS came from. >From a more recent perspective this is foolish (or at least naive). > > In addition to these features, the module would keep track of the > > amount of data transferred in & out for each vhost and apply a > > soft/hard limit when the limits defined in the LDAP entry were reached. > > The amount of actual data transferred would periodically be written to > > either a GDBM file or even to an LDAP entry (not sure what is best - > > probably LDAP for consistency) and the data would also need to be > > shared among any servers in a cluster somehow. > > This would enable ISPs to bill on a per vhost basis fairly accurately, > > and limit abusive sites. This part of it should be separate from the vhosting side of things. How you provision a web site is independent of how you accumulate stats on it. It's a logging module, which is naturally separate from a URI->filename mapping module -- though a proper vhosting module needs to hook into the DirectoryWalk side of things to do permissions. > > Will another method give me what I want? (LDAP is not a dependency, > > just a nice-to-have) Clever application of .htaccess files, sections containing AllowOverride directives, etc. *may* be good enough, but it's a very blunt tool. Sounds like you're aiming for something good. Lots of people have asked me for database-driven mod_vhost_alias (which misses the point, but) so there is a clear need. Don't worry too much about the project management side of things -- just write the code and the docs and publish it, then keep polishing and answering emails. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ BERWICK ON TWEED TO WHITBY: SOUTHEAST 2 OR 3, INCREASING 4 PERHAPS 5. FAIR. MODERATE OR GOOD. SLIGHT, INCREASING MODERATE LATER.
Re: Mass Vhosting SuExec (was Re: [PATCH] remove hardcoding of suexec log location)
On Thu, Jan 02, 2003 at 01:23:07AM +, Colm MacCárthaigh wrote: > > suexec will never "work correctly" with vhost_alias, or mod_rewrite :) > How would you tell it what username/group to use ? The approach used where I developed mod_vhost_alias was to get them from the ownership of the script that is to be run. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ NORTH FORELAND TO SELSEY BILL: SOUTH 4 INCREASING SOUTHWEST 6 OR 7 THEN EASE 5 OR 6 BEFORE VEERING NORTHWEST 6 TO GALE 8. EASE LATER SOUTHWEST 5 OR 6. OUTBREAKS OF RAIN, HEAVY AND PERSISTENT AT TIMES. MODERATE. MODERATE TO ROUGH.
Re: 2.1 repository?
On Fri, Aug 30, 2002 at 09:47:28AM -0700, Justin Erenkrantz wrote: > > And, I'd like to seriously consider using Subversion rather than CVS. > To me, it makes a lot of sense to switch to Subversion now rather > than later. If we do start on a model where we 'branch early and > often,' Subversion can handle the branching in a much better way > than CVS can (and more scalable to boot). The subversion web page says that it can't handle repeated merges, and still won't be able to until after 1.0. If 2.0 and 2.1 aren't going to diverge in an awkward fashion while parallel development continues, then this feature is a MUST. The Apache project's dislike of branching seems slightly odd to me given that it seems to work quite effectively over long periods of time in the BSD projects. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ LUNDY FASTNET IRISH SEA: WEST VEERING NORTH OR NORTHWEST 6 OR 7 DECREASING 4 OR 5. RAIN AT TIMES. MODERATE OR GOOD.
Re: apache freebsd port --enable-so
On Tue, Jul 23, 2002 at 11:43:54PM +0100, Dev Zero G Ltd wrote: > How can I make "make" compile/configure/make apache 2 with the > --enable-so option? I can not run ./configure since I already have a > Makefile. If you are using the FreeBSD port then it does --enable-so by default. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ DOGGER: WEST OR NORTHWEST 4 OR 5, OCCASIONALLY 6 AT FIRST. SHOWERS THEN RAIN. GOOD BECOMING MODERATE.
Re: Client socket
On Thu, May 30, 2002 at 11:03:05AM +0530, Vinod Panicker wrote: > > I need the actual socket that apache uses to communicate with the client > in the php module. Is it available somewhere in the request_rec > structure? You've already found it in r->connection->client->fd. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ SOUTH FITZROY: NORTH OR NORTHEAST 4 OR 5, OCCASIONALLY 6 NEAR CAPE FINISTERRE. FAIR. GOOD.
Re: Client socket
On Wed, May 29, 2002 at 04:27:59PM +0530, Vinod Panicker wrote: > > This script I call from the browser, and everytime it displays a '3'. I > even called it from different browser windows, still the same. > > That cant be alright since if the fd is 3 as shown in one browser > window, it has to be something different in the other window since the > browser defaults to a keep-alive connection, and the fd's have to be > different. Each connection is handled in a different process and each process's fd 3 is different. If a process fork()s two children and each child accept()s a connection they will each receive a different connection but it will be allocated the same fd number in each child. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ CROMARTY: SOUTHEASTERLY VEERING SOUTHWESTERLY 5 OR 6, DECREASING 4. RAIN THEN SHOWERS. MODERATE BECOMING GOOD.
Re: Fields delimiter in new "full" log format
On Thu, May 16, 2002 at 03:50:39PM +0400, Leonid Antonenkov wrote:
>
> Not the best, but, I think, better than current solution
> is to define long delimiter with rare characters (for example ' |:| ')
>
> Format string will be like this:
> LogFormat "%h |:| %l |:| %u |:| %t |:| %r |:| %>s |:| %b |:| %{Referer}i
> |:| %{User-Agent}i" new_combined
That doesn't avoid the need for escaping. Before the current effort
to properly escape log lines and to be strict about the request line
format (and you also need to be strict about all other request headers),
the only way to reliably log in Apache is to use a newline delimiter
between fields and a double newline between log records, so instead of
one line a log record would be multiple lines. This is more convenient
for software than for humans, though...
I also suggest adding X-Forwarded-For to your full log, to get some
details of proxy forwarding.
Tony.
--
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
SHANNON: SOUTHERLY 5 TO 7, DECREASING 4 IN EAST. RAIN THEN SHOWERS. MODERATE
BECOMING GOOD.
Re: Apache History Project - Call for comments
On Sat, May 11, 2002 at 09:23:58AM -0700, Aaron Bannert wrote: > On Sat, May 11, 2002 at 12:16:48PM -0400, Jim Jagielski wrote: > > > > +1. I think it's a great idea... I'd like to propose it as an > > ASF (sub)project. > > +1 from me too. +1 Tony.
Re: filehandle caching and nfs
On Thu, May 02, 2002 at 04:49:45PM -0600, David Bishop wrote: > > I have a problem with our apache webserver (v. 1.3.14), running on solaris 7. > A lot of our directories are auto-nfs mounted (esp. the ~username stuff). > 95% of the time it works great, however, intermittently, it will return "no > such file or directory", for files that were there 5 minutes before, and > still are there if you rsh to the webserver and look at the filesystem. And, > most importantly, refreshing the page "fixes" it (i.e., returns the correct > page). > > My theory for what's happening is that the automounter daemon unmount the fs > after 5 minutes of inactivity, but that apache "caches" the filehandle that > it used the last time. Then, when you go to hit that page again, it looks at > "/amd/u2pesfs2/blah/foo", rather than "/u/blah/foo", which (obviously) > doesn't work as the /amd/... has been unmounted, and isn't automatically > remounted just by referencing it (as opposed to /u/...). It then returns a > 404, and flushed the fh out of it's cache. Thus, the next time you request > the page, it goes for the /u/blah/foo, the fs is automounted again, and > everything is fine. I have seen this problem before on a Solaris system that was doing large scale virtual hosting, and the mapping from virtual hosts to physical directories was done via the automounter (rather than via symlinks as one would do on other unices). The problem is nothing to with Apache itself, but Apache exposes a performance problem in the Solaris auto mounter. The problem became more noticable as the load on the system increased. In the typical case path lookups that go through an automounted directory hit a cache in the kernel, and it happens that this cache lookup is faster - O(1) - than a UFS directory lookup - O(N) - for large directories, hence using it for large-scale vhosting. When the cache lookup fails, an upcall is made to the userland automountd, which does a lookup in the automount tables -- which in my case were large text files, and in your case may be the password file or NIS maps. The upcall to the automountd is expensive, and the automountd only handles one upcall at a time. The problem is that the kernel does not do negative cacheing of automount lookups, so if you repeatedly request a missing file in an automounted directory you can overload the automountd. In this situation, you don't block waiting for the automountd, you get an error return. I can't remember exactly the errno value, but the result was a "403 Forbidden" from Apache. This might have changed in more recent versions of Solaris -- we were running 2.6, and ISTR reporting the problem to Sun but before they got anywhere near a fix (which took far longer than we could wait) I had an adequate work-around so I didn't pursue a proper solution. They might have just changed the errno value to ENOENT... The feature of Apache that caused this overloading of the automountd is that it looked for .htaccess in the automounted directory on every request, which caused a cache miss and a consequent upcall to the automountd on every request. You can spot that this is happening if the automountd is using an implausible proportion of the CPU. In our case the automount maps were text files which were loaded and parsed for every automountd request, which is what caused the unnatural CPU usage and time delay on automountd requests; if you are using a different source for automount maps (particularly NIS) then your failure mode will have different details. The solution is either to alter your Apache configuration so that it doesn't look for .htaccess files in the automounted directory, e.g. (I think -- try it and see) instead of AllowOverride all (which looks for /home/.htaccess on every request) do AllowOverride all Alternatively (if you have the right kind of automounter configuration) add a bogus .htaccess entry in your automount maps which causes the kernel cache lookup to succeed with a reference to an empty file or something equally inoccuous. Pointing strace at the automountd will tell you if my guess is right. If it isn't, at least I got to tell an amusing war story. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ BAILEY: VARIABLE BECOMING SOUTHEASTERLY 3 OR 4, INCREASING 5 OR 6 IN WEST LATER. SHOWERS. GOOD.
Re: mass-hosting and DOCUMENT_ROOT
On Mon, Apr 29, 2002 at 06:15:13PM +0200, Marten Lehmann wrote: > > My idea is to write my own apache-module, that does the host to path > translation and additionally set the DOCUMENT_ROOT variable. But before > I start, I would like to know (because you possibly have more knowledge > about the internal apache-design than me), if it is possible to set this > environment-variable in this phase so it takes effect in the later > content-processing. I tried to set the variable inside my > mod_perl-handler, but when the script I called through http was > executed, the standard-document-root appeared again. This won't work because your setting will be overriden by the server's core module. You have to either (1) tell your users not to use the DOCUMENT_ROOT variable because it's a non-standard extension whose value is often wrong; (2) do a quick-and-dirty hack to the core for your installation; (3) fix it properly so that environment handling is federated rather than under the core's control. Tony.
Re: Email addresses in changes file
On Wed, Mar 27, 2002 at 09:36:31AM -0800, Joshua Slive wrote: > On Wed, 27 Mar 2002 [EMAIL PROTECTED] wrote: > > Anyone think it is a good idea if I did a > > > > s/@/_at_/g > > > > on the email addresses in the Changes file ? > > -0 > > - It won't solve the problem. > > - It looks amateurish - The change is too late for most contributors. - The email addresses are in the mailing list archives and the bug database. Tony.
Re: v2.0 + threading under FreeBSD v4.5 ...
On Tue, Mar 12, 2002 at 04:16:41PM -0800, Justin Erenkrantz wrote: > > I bet part of the problems may be our own fault and others may be > because FreeBSD's threading implementation isn't (yet) very solid. > Regardless, if you *need* threading, use another OS. -- justin My understanding of the situation is that FreeBSD's threading is very good, unless you use SYSV semaphores which aren't intercepted by the userland threading library and so block the whole process. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> TRAFALGAR: SOUTH OR SOUTHWEST, VEERING WEST 6 TO GALE 8. THUNDERY SHOWERS. MODERATE.
Re: Torching ap_document_root
On Fri, Mar 08, 2002 at 12:49:16PM -0500, Rodent of Unusual Size wrote: > > Greg, please take a step back and ask yourself: what *harm* > does it do for modules to know the DocumentRoot? If it does no > harm, then standing in the way of others just because you can't > think of an application *does* do harm. There is no problem with it in principle, but the current implementation is broken. It is too tied to the core's idea of the URI->filesystem mapping and modules are unable to fix that when they know better (mod_vhost_alias, mod_userdir, ...). Tony.
Re: Torching ap_document_root
On Thu, Mar 07, 2002 at 08:23:35PM -0800, Sander van Zoest wrote:
> On Thu, Mar 07, 2002 at 02:25:56PM -0800, Greg Stein wrote:
> >
> > Modules shouldn't be worried about the document root. If you need to call
> > this function, then you should ask yourself "why". Modules should be more
> > concerned with r->uri and r->filename.
This also applies to CGIs. The DOCUMENT_ROOT environment variable is
a non-standard extension so it should be avoided.
> In the case of using a CGI with mod_vhost_alias it would be
> nice to be able to have the CGI have access to the virtual document root
> via ENV{DOCUMENT_ROOT}. Right now this doesn't seem possible because
> mod_vhost_alias does not have access to it and otherwise
> ap_add_cgi_vars(r) resets it if we set it via r->subprocess_env in
> mod_vhost_alias.
There are a number of other situations in which the document root setting
is irrelevant, such as normal aliases, mod_userdir, and mod_rewrite;
mod_vhost_alias just makes it more obvious that this is so.
The right fix for CGIs is to allow modules to participate more fully
in setting up environment variables, so that e.g. modules that do
URI->filename mapping can override the DOCUMENT_ROOT setting.
Tony.
--
f.a.n.finch <[EMAIL PROTECTED]>
FAEROES: SOUTHERLY VEERING WESTERLY, 4 OR 5 INCREASING 6 TO GALE 8, PERHAPS
SEVERE GALE 9 LATER. RAIN THEN WINTRY SHOWERS. MODERATE OR GOOD.
Re: UseCanonicalName considered harmful
On Wed, Feb 06, 2002 at 07:45:44AM -0800, Ryan Bloom wrote: > > The Port directive was removed from 2.0, because it confuses too many > people. Good :-) Tony.
Re: UseCanonicalName considered harmful
On Wed, Feb 06, 2002 at 09:44:22AM -0500, Rodent of Unusual Size wrote: > > Let's see, then. Here are some test cases: > [...] > Does that seem about right? Yes, with the addition that any Port directive is used to create the canonical name in preference to the port from the Listen directive, i.e. ServerName dotat.at Port 8000 is the same as ServerName dotat.at:8000 Tony.
Re: Version numbering
On Thu, Jan 31, 2002 at 03:53:29PM -0500, Rodent of Unusual Size wrote: > Eh.. 2.0.31 and climbing.. > > When we *do* go GA, are we planning on keeping this numbering? Didn't we decide the answer to that question months and months ago after several lengthy flame wars? Tony.
Re: A question for the protocol gurus...
On Wed, Jan 30, 2002 at 12:35:58AM +0200, Graham Leggett wrote: > > On the proxy list there is talk of support for transparent-proxy > behaviour, and the question has come up "what about HTTP/0.9?". Am I > correct in saying it is not possible to find the destination server if > the protocol is v0.9 or v1.0, and there is no host header, and there is > no complete URL in the request (ie http://server.name/blah instead of > just /blah)? Or is there some trick to do this? When transparent proxying you use a trick (usually a special in-kernel firewall config) to accept connections to any IP address, and you use the destination address of the connection to determine which upstream server to forward the request to. The only time you get a complete URL in the request is if the browser is configured to use a proxy, which is not the case for transparent proxying (unless you are putting the transparent proxy in front of a proxy, but that's mad). Tony.
