Tag Archives: apache

Redirecting documentation

I just spent an inordinately long time trying to get a simple documentation redirect working.

This was suggested to me by the recent discussion on PHP, where it was noted that http://php.net/foo takes you directly to the documentation on the function foo. Which is, of course, a really cool feature.

So, I decided that the Apache docs need that too. But while this would be really easy to do with, say, php, or perhaps a mod_perl handler, I wanted to do it with stuff that comes with Apache. mod_rewrite seemed like the obvious choice.

There are, however, a number of obstacles. mod_rewrite is, to put it nicely, documented in a user-hostile manner. Particularly in a beginner hostile manner.

I had already decided that I needed to use RewriteMap, because I have a large number of URLs that I want to redirect, and I want that list to be easily updateable. So, using a simple Perl script, I generated a starter map file from the XML documentation source:

#!/usr/bin/perl
use XML::Simple;

foreach my $file(@ARGV) {
    my $doc = XMLin($file);
    
    my $mod = $file;
    $mod =~ s/^.*mod_//;
    $mod =~ s/.xml$//;
    
    my $directives = $doc->{directivesynopsis};
    foreach my $d (keys(%$directives)) {
        next unless $d;
        print "$d http://httpd.apache.org/docs-2.0/mod/mod_$mod.html#$dn"
    }   
}

Running this script:

xml2rewritemap mod_rewrite.xml

generated a starter rewrite map. A single line of this file looks simply like:

RewriteMap http://httpd.apache.org/docs-2.0/mod/mod_rewrite.html#RewriteMap

So far, so good. If this works, it’s a simple matter to generate a map for the entire documentation tree, since it’s all in XML.

Then, in httpd.conf, I put the following:

RewriteEngine On
RewriteMap directive2url txt:/www/vhosts/drbacchus/fajita/scripts/rewritemap.txt

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/([^/]*)$ ${directive2url:$1} [NC,R]

So that creates the mapping function “directive2url”, pointing at the rewritemap file I generated. And then it runs that function on any URL which generated a 404. (Yes, that’s slightly over-simplifying.)

And it almost works. Going to http://fajita.drbacchus.com/RewriteMap *almost* redirects you to the desired location. Unfortunately, the # gets converted to a %23, which, in turn, generates a 404.

Well, after a bit of rooting around, it turns out that this exact problem is covered in the RewriteGuide (Look for “extended redirection”) and that it’s actually by design. Hrmph. Well, I may end up doing this without mod_rewrite. But it will be very disappointing. Perhaps I should agitate for a DoNotEscape flag for RewriteRule so that stuff like this isn’t such a pain.

Or maybe there already is one, and I’m just missing it because the mod_rewrite documentation is written for people who have already read the code. *sigh*.

IRC philosophies

Well, this started as a response to a comment, but I kept writing, and writing, and … decided it should be an article.

Someone named Joey made some remarks about the difference in philosophy between #php and #apache. His remarks have a certain degree of truth in them, and are, I expect, the exact thing that I’m reacting against, because he describes exactly the attitude that tends to fill IRC channels, but is, in *many* cases, translated into a self-important newbie-hating pomposity that makes beginners feel stupid and timid about asking their questions. That’s counter-productive, and makes free/open source software seem like a pack of elitist blow-hards. Which, to an extent … nevermind.

First, the cliche “the pot calling the kettle black”, not the other way around. But that’s probably not particularly important.

We never, ever, send people to #php for issues involving vhosts, permissions, authentication, or mod_rewrite. Ever. The fact that people come to #php first with those questions merely says that they are PHP users, not that we sent them there.

I would also question the notion that everything is necessarily clearly either a PHP question or Apache question. As you may have noticed, there’s a bit of overlap. You have noticed that, right? It’s one of the reasons that I find the animosity rather amusing. It’s also amusing that this rather tongue-in-cheek article prompted a slashdotting, of all things. As someone on a local mailing list noted, I’ve successfully trolled the entire open source community.

Anyways, folks are sent to #php when there are PHP-related questions that we can’t answer. Presumably, that’s a pretty clear indication that sending them back is just going to waste their time. If we didn’t know before we sent, we won’t know after they come back. It’s just an indication that we thought, probably, since the question was in the general vicinity of PHP, that someone there might have had experience with it.

Asking beginners to make some kind of clear distinction between where Apache leaves off and PHP starts is unreasonable. The self-important pedantry that inhabits most IRC channels is pathetic, not really something to boast about. Where there are clear areas of overlap, it’s reasonable to help folks out, rather than yelling RTFM.

So, no, this is not a case of the pot calling the kettle black at all. It is, as my initial posting was, a request for two communities to do a better job of cooperating. Could you possibly get off of your need to assign blame, and consider ways that we can cooperate?

Oh, and, for the record, _in my opinion_, IRC channels that insist on being topical, to the exclusion of interesting *related* conversation and socialization, are BORING, and do nothing to foster community. And, yes, I completely agree that this is a difference in philosophy, but it seems one that most IRC beginners appreciate enormously. The number of times we get “You guys aren’t jerks like folks on most IRC channels” completely makes up for the higher background noise.

Most of my pots are silver, and my kettle is white, with pictures of apples and apple pies on it. Pots and kettles don’t enter into this, really. You’re right, it’s a difference in philosophies. Our philosophy tends to be (or at least mine) that I have arrived where I am today because of the kindness of strangers who helped me solve problems when I was a clueless noobie, and that it’s a nice thing to return the favor to other strangers. When folks come in and ask questions, I try to answer them if I can. If someone asks something that I can answer, but is “off topic”, the standard IRC thing to do, apparently, is to flame them and move them along. I find that to be rude and unprofessional. Yes, absolutely, showing people where to find answers is a good thing. But what we hear (and what I’ve observed while lurking) is that #php treats people discourteously, and treats them like stupid children, rather than like fellow professionals.

I’m certainly not disagreeing with you, Joey, that we have different philosophies. I’m asking that you embue your philosophy with a little respect, and a recognition that “ignorant” and “stupid” are completely different concepts, and that most of the people asking these questions are experts in areas of which you are totally ignorant. Please, don’t take that as a personal accusation. But my experience on #php has been that asking a question resulted in being called an idiot and told to go elsewhere. I’m not an idiot, I’m reasonably sure, and I presume that most of the people called that on IRC are likewise not.

Welcome, Slashdot visitor

I’ve yet again been subjected to a Slashdotting in response to my earlier remarks about PHP. Unfortunately, this time around, the story was rather far off in its interpretation of my remarks.

For Pete’s sake, folks, maybe you could actually read what is said before you unleash Slashdot on me.

A few clarifications:

I do *NOT* speak for the entire Apache community. Remarks that I make are my remarks, and are not supposed to represent the feelings of the entire Apache community.

I am *NOT* either pissed off, or angry, and it is *not* about PHP not recommending the use of Apache 2.0. It’s about them actively discouraging the use of Apache 2.0, for somewhat incorrect reasons. That’s *NOT* the same thing.

I am *NOT* saying that everyone should migrate to Apache 2.0. I don’t think you’ll see me saying that anywhere. Sure, it would be nice if people migrated, but some people don’t have any particular reason to. I’ve *NEVER* been an advocate of upgrading for the sake of upgrading, and that goes for almost all software. However, if people have a legitimate reason to move to 2.0, it is irritating that their reason for not doing so is a remark on the PHP web site which is, in my opinion, based on fallacy.

It bugs me that when I bring this up, the response is “I don’t want to migrate to 2.0 because 1.3 is rock solid.” That’s wonderful, but *completely* unrelated to what I’m talking about.

Yes, perhaps the term “FUD” was ill chosen in this context. Sorry. I was trying to provoke a conversation. Fortunately, the folks on PHP-DEV are intelligent enough that it provoked the right conversation. That’s very encouraging. The conversation is not about whether everyone should move to 2.0. It’s about whether PHP should actively discourage this move, or whether they should give helpful information to folks that *want* to make that move.

I sincerely hope that folks can grasp the distinction that I’m trying to make. Apparently “anonymous reader” was unable to do so. And, as a result, my poor little web server is having fits.

*sigh*

Conversation over on PHP-DEV

Apparently I sparked a conversation over on PHP-DEV, with some very good commentary, as well as very clear explanations by Rasmus. Thanks, folks, for considering this important enough to discuss. It sounds to me like the tone of the conversation is in a good direction — or at leasts the direction I was hoping to influence it.

Yes, the AddType/AddHandler thing is, as Rasmus says, purely academic. A pet peeve, nonetheless, but purely academic. I’m over it. However, it *is* 8-year old syntax. 😉

And, for the record, once again, PHP is a great piece of work. Thanks to Rasmus and everyone else for their work and tireless absorbtion of our constant abuse.

PHP’s anti-Apache2 FUD

My biggest objection to PHP is the anti-Apache2 FUD that they spread. Indeed, they seem to be the ones primarily responsible for the anti-Apache2 FUD. This is unfortunate, since there are few remaining legitimate reasons for avoiding Apache2, and it’s a shame that they feel the need to manufacture one.

So, to quote the PHP docs:

Do not use Apache 2.0.x and PHP in a production environment neither on Unix nor on Windows.

This is further clarified in the FAQ with a long description which starts, unfortunately, with a misconception, namely:

The major feature that draws people to Apache 2 is threading.

It then goes on to explain why threading is, potentially, a problem with PHP, why this is not, technically, PHP’s fault, and so PHP cant fix it. All very correct, really. And, so, very logically, it concludes that there’s no reason to move to Apache 2, and that everyone should stick with Apache 1.3.

This argument suffers from one main flaw. That is, that the initial assumption, from which everything flows, is just plain wrong.

Yes, threading is cool, and is a major shinyness with Apache 2. However, it is not, by any stretch of the imagination, the only, or even the main, reason for moving to Apache 2.0. There are a *lot* of other much better reasons for moving to Apache 2.0, none of which pose any threat to PHP. I’ve covered those in my OnLamp article, and so won’t repeat them here. Apache 2.0, running with a prefork MPM, works great with PHP, and gives you all those other benefits.

The additional benefit is a little more subtle. Apache 1.3 is becoming “legacy”. Meaning that the real developers are focusing more on 2.0. The 2.0 docs are better. 2.0 (and 2.1) gets the new features, the documentation improvements, and the newly clarified directives and error messages. Thus, 1.3 becomes harder and harder to support. So, increasingly, the PHP questions are coming from folks that are running 1.3, and the solutions offered just don’t work, because they are things added in 2.0 to solve exactly the irritations that these folks are having.

So, I entreat the PHP folks to remove this incorrect anti-Apache 2.0 tirade from their documentation, and replace it with a more balanced and correct explanation of the issues involved, and the recommended solution. Namely, that people go ahead and move to Apache 2.0, but stick with a Prefork MPM. This gives them most of the benefits of Apache 2.0, but removes the irritating threading issues. Nobody blames PHP for those threading issues (at least, people who have taken the trouble to actually understand the issue don’t), so there’s no slight on the PHP developers implied here. I’d be glad to participate in this to any degree that you like. I actually enjoy writing documentation, and I’m increasingly using PHP for my own work.

Please?

Why we don’t like PHP

I’ve started using PHP lately, and I find that I quite like it, as a language. However, there’s a lot of anti-PHP sentiment on #apache (on freenode.net), and folks often wonder what the source of that is. Well, there’s several main reasons, some of which are:

  1. The anti-Apache2 FUD spread by the PHP folks
  2. The #php redirect effect
  3. The “scripture with commentary” nature of the documentation
  4. The misuse of AddType vs AddHandler

The first one of these, the anti-Apache2 FUD issue, is one that’s important enough that I’ll probably write as a seperate article.

The next one, the “#php redirect effect,” is pretty irritating. On #apache, we attempt to be very helpful, and so we end up answering questions on a variety of topics which are, strictly speaking, off-topic. Invariably, however, when we refer someone to #php for questions which seem to be likely to be more in the experience of folks familiar with PHP, they say, that’s an Apache problem, and send them back to #apache. This is very irritating behavior, and results in a lot of frustrated people with unanswered questions. There are indeed questions which are, strictly speaking, Apache questions. However, when they are configuration issues which would necessarily be more familiar to frequent users of PHP, it would be courteous if they were to be willing to handle those questions.

The third issue is one on which, obviously, a lot of people disagree with me. I find the PHP documentation deeply irritating. The model that they have chosen, which I call the “Scripture with commentary” approach, works kinda like this. Someone – the authority, one presumes, writes a brief piece of official documentation. Then dozens of the masses write additional commentary as addenda to that official documentation. These comments might be correct, or they might not. Who’s to know? There doesn’t seem to be any official method for resolving those comments back into the official documents. So you can’t actually know which bits are true, and which bits are uninformed ignoramuses. Then, too, there are a lot of heretical remarks, which simply criticize or complain. These are not only unhelpful, but they distract from the main flow of the truth, and so further serve to confuse the issue.

However, I should say that the PHP docs get a lot of acclaim for being wonderful, so there are obviously a lot of people that disagree with me.

Finally, there’s something that amounts to not much more than a pet peeve. The PHP docs recommend the use of AddType to enable php parsing:

AddType application/x-httpd-php .php

That’s just *wrong.* The correct way to do this would be to use AddHandler. Using AddType confuses people about what AddType means. So you should instead use:

AddHandler application/x-httpd-php .php

What’s especially irritating is that both work. But it’s still wrong.

AddType associates a Content-Type with a file extension, and that tells the browser how to deal with a particular data stream. AddHandler, on the other hand, maps a handler to a file extension.

Stated more simply, AddType tells the browser what to do with a file, and AddHandler tells the server what to do with a file. PHP is handled by the *server*, not by the browser, and so AddHandler is more appropriate.

So, you see, none of these are technical objections with PHP itself, but more deal with the community. It’s a shame when technical communities are divided by community issues, rather than technology issues. But it seems that that’s almost always the way of it.

So, once again, for the record, I’m becoming quite fond of PHP, almost in spite of myself. It makes development quick and easy. If one can get past other objections.

Building webalizer with –enable-dns

After searching at great length, and following many blind alleys, I found an imprecise reference to the problem that I was having. So, to save you that time, here’s the deal.

If you want to build webalizer with DNS lookup abilities, ie, using the –enable-dns flag to ./configure, you need to edit two files.

In webalizer.c you need to change

#include <db.h>

to

#include <db1/db.h>

In dns_resolv.c you need to make exactly the same change.

That is all.

ApacheCon Cometh

We’re coming down to the last few days before ApacheCon. We’ve broken the mystical 300 barrier on registrations, but there’s still room for a lot more of you. I’m starting to get a little bit excited/nervous about the conference. I’m speaking 6 times, which, I assure you, is a clear sign of insanity. Or at least will lead to it.

You also should take a look at the ApacheCon Wiki, which should be picking up steam in the next few days. And you can probably virtually “attend” the conference on IRC, on #apachecon, on freenode.net. Not the same as being there, but still pretty fun.

Oh, and if you want to go GeoCaching at the conference, please, please, please let me know. It would be great to have some company.

Comment spammers are dumb

Over the last 48 hours or so, I’ve gotten upwards of 400 identical comments on my blog. Fortunately, comment spammers are really really stupid, so they were all identical.

I’ve got mod_security installed. I put the following block into my vhost block:

<LocationMatch comment>
SecFilterEngine On
SecFilterScanPOST On
SecAuditLog /dev/null
SecFilterDefaultAction “deny,log,status:402”
SecFilter “your[[:space:]]fat[[:space:]]ass”
SecFilter “poker”
SecFilter “phentermine”
SecFilter “craps strategy”
SecFilter “seend a card”
</LocationMatch>

This has blocked all attempts in the last 10 hours or so. And, when they change their tactics, you can alter the rules appropriately.