bmt online - archives

At last !

At last, my file with BCIS went through! As of last Monday, I am fully authorized to work in the US. This is quite a change, as opposed to before, when I needed companies to sponsor me to work, but now I still need a job...

I guess I should consider working at that pizza place down the street :-D

tue 2003-07-10

Conforming to the W3C standards

All the pages published on this web site are conforming to the W3 consortium standards, as indicated by the following tags:

What this means is that this page is stripped out of all the fancy buzz-technology that runs around the Internet, and that it will be happily displayed on any XHTML 1.1 conforming web browser. In particular, no proprietary HTML construct was used on the page.

This is to show that the author of the page is commited to produce quality, hand-crafted HTML code. It is not optimised for any version of any specific browser. It will be equally interpreted by Internet Explorer, Netscape, Mozilla, Lynx or your cell-phone WAP browser.

2003-07

How it came to be

When I started to compose this web site, early november 2002, I already had had some experience of creating my own web pages. It went along two lines:

On the one hand, I had already tried to create it by hand, and had only gotten myself drowned in the apparent complexity of HTML, as well as big page setup issues.
I had also tried to use WYSIWYG editors, MS Word not being the least of all, only to find out that the output code was... ugly as hell !

So this time, I decided that there would be no WYSIWYG editor in the process. I said to myself: I want none of that ! The problem was then to find a good resource on how to write correct (or at least correct enough) HTML code.

I think quite by chance, I came across the ALL HTML web site: a french resource web site for webmasters, offering a complete enough collection of information about all the tools that a webmaster can come across when designing his own website: HTML, PHP, JavaScript, etc.

So there I went, putting my first shot at the employment web site, following the good enough advice nicely published on ALL HTML. The end result was quite satisfying and things could have stayed as they were. However, while still having the website in mind, I came across the web page of a friend—Olivier Aubert [1]—which led me to the HTML validator of the W3 consortium.

So that's when I realised what had been bothering me all this time: I have the strong conviction that it is not the tool that makes the language, but the specification. I had been developing my web page with the only satisfaction that it was being interpreted as I more or less wanted by a web browser. What guaranty did I have that the code I had written was portable across browsers ? None. So I had my answer: there was indeed a specification for the HTML language, and there were tools to check the validity of a piece of code.

2003-07 last revised: 2004-04-16

[1] I used to know Olivier's home page address, but he has moved without notifying me. If you happen to know about his new cyber-whereabouts, please drop me a line.

Apache, PHP and MultiViews

A dedicated webmaster

As a dedicated webmaster, and a true geek, I am trying to create clean, straightforward code and organization for bmt-online. Thus, after installing Apache 1.3 on my Windows box, after installing PHP4, in order to have an easy document organisation on the site, after validating all the content with W3C, I started to think about how to organize my documents on the site.

While doing the validation, I came across an interesting article on the W3C site entitled "Cool URIs don't change". A whole program ! Suffice to say that I was convinced, and decided to take advantage of the facilities offered by Apache.

Thus, the current page, as I am writing this article, is a php script. Its canonical URL is :

http://www.bmt.dnsalias.org/geekisms

However, it would be equally valid to access it at:

http://www.bmt.dnsalias.org/geekisms.php

All this is fine, and I am pretty happy about my setup, except for one little detail: the CSS validation of the documents when refered by the "good looking" URIs was broken. Instead of congratulating me with my valid CSS, the validator now spit a hard and short error at my face:

I/O Error: http://www.bmt.dnsalias.org/: Not Acceptable .

Investigation...

After investigation, it turns out that this is the result of the conjunction of several independant factors. So, let's look at the technical details of my setup:

I set up PHP for Apache as a module. This apparently requires that a pseudo MIME type, application/x-http-php be declared so that the module correctly handles PHP files. The directive
```
    AddType application/x-httpd-php .php
```
in my Apache configuration file in effects makes all files with extension .php to be considered of type application/x-httpd-php.
To achieve the "good looking" URIs, I used the MultiViews directive of Apache. The description, taken verbatim from the Apache documentation is:

The effect of MultiViews is as follows: if the server receives a request for /some/dir/foo, if /some/dir has MultiViews enabled, and /some/dir/foo does not exist, then the server reads the directory looking for files named foo.*, and effectively fakes up a type map which names all those files, assigning them the same media types and content-encodings it would have if the client had asked for one of them by name. It then chooses the best match to the client's requirements.

The last part is important. Remembering that we attributed the media type application/x-httpd-php to PHP files, we see that while processing the content negociation request of the client, the server considers the PHP files as being of their own private type.
This is somewhat off, given that the actual type of the output of the PHP script is a genuine HTML page, with correctly set text/html content type, but, oh well, it doesn't do much harm. Or does it ?
The CSS validator at W3C is a picky web client. A capture of the packets exchanged between the validator and my server shows that it sends a quite peculiar Accept: field in its HTTP request.
```
    GET /geekisms HTTP/1.1
    Cache-Control: no-cache
    Date: Thu, 10 Jul 2003 00:06:02 GMT
    Pragma: no-cache
    Accept: text/css,text/html,text/xml,     \
      application/xhtml+xml,application/xml, \
      image/svg+xml,*/*;q=0
    Accept-Language: en-us
    Host: www.bmt.dnsalias.org
    User-Agent: Jigsaw/2.2.0 W3C_CSS_Validator_JFouffa/2.0
```
So, wait a minute, what ? This means that the validator accepts css, html, xml and a few other mixes of standard web publishing formats, and, */*;q=0, nothing else ?!?

Yes indeed, that's what it means. This client is picky, but it is its own right. It is not violating any standard, nor any rules of good conduct. It is just enforcing the fact that, being a CSS validator, it has to be served an *ML document.

Now, during content negociation, triggered by the fact that the client asked for a content-type-generic URI, the server found out that it was asked for *ML only content, while it was only able to deliver application/x-httpd-php content. Thus, complying with the HTTP 1.1 standard, it returned a 406 Not Acceptable response to the client, which in turn displayed it on its result page as the dry error above.

Where to go from there ?

When I found out about that problem, I started, of course, researching about it. There are several faqs and bug reports describing the problem around:

W3C report the problem in their CSS validator FAQ. In short, they say that creating a specific mime type for php files (with the AddType directive) is a misconfiguration of the server, and that the server should be configured to use the PHP module as a handler instead (with the AddHandler directive).
However, as far as I can tell, there is no mention anywhere in the PHP documentation that it has a handler ability when used as a module for Apache 1.3.
There is a bug report on the PHP web site, describing the problem, where the submitter of the bug recommends that the mime type for the PHP files be text/x-httpd-php instead of application/x-httpd-php.
However, noticing that the problem is solved with Apache 2.0, the bug report has been closed without being fixed. I do not think this is the right solution anyways. A PHP script is basically allowed to produce an output of any content type. If the server has to do anything, it's to analyze the output of the script, and classify the document accordingly during the content type negociation. Talk about heavy duty...

I have tried to bring up the matter on comp.lang.php, to no avail. On the #php channel on IRC, I have been told to read the fscking manual :-(.

In any case, nobody was able to tell me if there was a known workaround for the issue, or if there was a way to install PHP for Apache as a module invoked as a handler, or any way to modify the dreaded mime type application/x-httpd-php and still have the scripts correctly processed by PHP.

I have had a look at the code of the PHP module. The mime type is very much hard-coded in there, as evidenced by the following excerpt from the code:

    handler_rec php_handlers[] =
    {
      {"application/x-httpd-php", send_parsed_php},
      {"application/x-httpd-php-source", send_parsed_php_source},
      {"text/html", php_xbithack_handler},
      {NULL}
    };

I thought there might be some hope with the line containing text/html. It handles the so-called x bit hack, which allows PHP to "parse files with executable bit set as PHP regardles of their file ending". However, it is no more than a hack as its name indicates, and it does not work as expected under a Windows system.

A story in the making

As it is, I still haven't found a satisfying way of solving the issue. If a certified PHP geek is able to devise a viable workaround, he is more than welcome to contact me and let me know about it.

wed 2003-07-09

If americans knew

Today, I assisted to a quite interesting conference by Alison Weir where she exposed the very biased coverage of the current Israelo-Palestinian conflict in the american media.

Quoting the website of If Americans Knew, I want to report the following data: from April to September 2002, the San Jose Mercury News, the Bay Area's largest news and information Web site, reported 140 Israeli deaths and 20 Palestinian deaths on their front page headlines. During the same period, the Israeli human rights organization B'Tselem reported an actual 192 Israeli deaths and 383 Palestinian deaths. In other words, the Mercury News reported 73% of the Israeli deaths on their front page headlines, while only reporting 5% of the Palestinian deaths.

If you think, like I do, that this is not the way independent journalism should work, if you want to learn more about the Israelo- Palestinian conflict, if you want to find out what you can do, please check out If Americans Knew.

tue 2003-07-08

bmt online is moving... again...

Our friends at Da Pleasure Lounge have sadly had big trouble maintaining their DNS record, so that access to http://bmt-online.dapleasurelounge.com has been erratic at best.

In the meantime, I was able to set up a fairly good working web server on my home computer, which, linked with the free service to the community offered by DynDNS.org, allows me to now host bmt online myself.

Thus, I give you the brand new bmt-online at

http://www.bmt.dnsalias.org/