People usually goes to the seaside at the weekend. But here it was snowing. So, I thought about setting up some geeky stuff.
First of all, upgrade of my ubuntu server to Gutsy Gibbon. Quite smooth, even if I did it via ssh and with an ever-dropping connection. Just apache: complains about port 443 used by someone else, and it was itself. Removed it from /etc/apache2/ports.conf, since already present in /etc/apache2/mods-enabled/ssl.conf.
Second: now I have an alpha server at home. Got some difficulty, since I never worked on an alpha neither do it via serial line (given alpha was configured to use only serial line as input/output). But, at last, ralph the alpha is up. Ralph, just like Ralph Waldo Emerson, oh my dear, nothing less. aboot - the boot system for alpha servers with SRM consoles (wonderful thing, by the way) - still does not boot up right, complaining about a unknown zip compression, but when I give him the boot stuff by hand, it starts smoothly. I had just to add a console=ttyS0 by hand and the corresponding entry in /etc/inittab, and it was all ok. It’ll start crunching numbers (see: running antispam, computing graphs and keeping the mysql db) as soon as I can configure it. Veeeeery nice.
Posted by mattia as apache, ubuntu at 10:05 PM CEST
No Comments »
It’s a problem when you write diagrams like this. It’s a bigger problem is you really understand them.
Posted by mattia as apache, cluster, diagram, sketch, squid, zope at 12:57 AM CEST
No Comments »
I suppose that if you pass by this blog, you’re geek. I meant, a programmer. Excuse me, sometimes I forget the difference.
What difference?
I’m going out topic. I just wanted to underline a thing: when we validate a page as XHTML 1.0 Strict or 1.1 with W3C Validator or similar validators, we’ve not done all the work.
Why? Because we often forget one thing: the Content-Type.
Content-Type is one of the HTTP headers from the server. To be exact, it specify the MIME type of the object returned. On the GET call from the browser, we have the corresponding Accept header which tells us which kind of Content-Type the client can accept, so at server side possible transformations can occur to provide the best one. E.g.: if a browser does know nothing about SVG, it won’t send in the Accept header the value “image/svg+xml” (which tells us: we’re talking about an image, whose type is both svg and xml - in fact svg is just an XML application, so this definition is correct). So, it could be possible for the server, in theory, if it finds a client that cannot handle SVG, to perform locally the transformation into another non-vectorial type and send it: this process is called content negotiation. The client is always right, and, moreover, gets what it asks. It all boils down, at the end, at the old, and somehow still valid, philosophy of internet: dumb client, intelligent server.
Back to XHTML. As for specs, XHTML 1.1 should not be sent with Content-Type (aka media type) text/html, which is the standard for all HTML, but with type application/xhtml+xml (as you can see, the syntax is analogout to image/svg+xml), and it seems that XHTML 2.0 must be sent with Content-Type application/xhtml+xml (I’m referring to standard w3c/ietf terminology, look at here for the exact meaning). So, it seems simple: we change the headers sent according to the way our framework allows us to do it, and we’re fully compliant.
Well, no. Sadly, Internet Explorer, event the new-born 7 serie, does not accept that type of content-type, showing it without style (well, I couldn’t reproduce it under wine, but I assure you it’s this way). The reason is explained here. I can’t say there’s no good reason on it, but the fact remains. So?
As I said, the Accept header in the request it’s there to tell which kinds the browser accept, and make the server adapt. But in this case is just too easy: valid XHTML 1.1 is also valid HTML, so a downgrade to text/html is always correct for every XHTML 1.1 document without any change (I admit I’m not completely sure this is true by standard, but surely is true by common browser implementations)! So, it’s enough to decide the reply Content-Type header according to the Accept types.
(To speak the truth, normal content negotiation, which here I cut down to the minimum, cannot be applied as for standard, otherwise, you could send anyway application/xhtml+xml to explorer and use text/html instead for Opera and Safari - this is because their Accept header isn’t completely coherent with the philosophy behind it, and this is the result)
Notice one more thing: text/html and application/xhtml+xml are really different, if you understand the logic behind. text/html doesn’t claim to be XML, application/xhtml+xml do. This means that if a text/html isn’t correct XHTML, it’s okay anyway for a logical browser engine (spelled as Gecko, or KHTML), whereas if an application/xhtml+xml is no XML in truth (one common problem: the use of non-entity ampersand - & - thanks to default PHP setting arg_separator.output; change it to & to get a sensible result), then we have a syntax error. And, for example, Firefox/Mozilla is really picky about this: if you have a wrong XHTML page served as text/html, it will fall back in normal mode and parse it anyway (e.g., the ampersand error above isn’t even recognized by W3C Validator!), but if you serve it as application/xhtml+xml, it shows you a menacing page with nothing more but an error:
But this is useful. Lax HTML had proliferated, making life harder and harder for automatic tools to be written correctly, just because browser accepted it. But if they stop, because you’ve declared a strict media type, no more wrong code will start going on the net. Moreover, HTML is full of non-semantic, visual-targetted tags, whereas XHTML stands on the semantic side. Since you now validate to a certain doctype, we make sure that we also stop using non-semantic tags. All in all, we both need power as much as restrictions to make things go the right way, and since both can be automated, both are. And we’ll all be finer.
To make the long story short: for Wordpress you can find this über-simple plugin (and, as many über-simple things, well working: KISS philosophy) which does exactly the browser-dependant media type workaround: XHTML Mime Plugin. And then, you’ll be 100% XHTML compliant. Ah, what a geek thing!
Posted by mattia as apache, wordpress, xhtml at 3:06 PM CEST
No Comments »
I suppose that I’ll keep swearing against technologies on this blog for a long time. This round is the turn of PHP4/PHP5 on the same server. I wish to know: how was it possible that phpinfo() showed PHP version 5, while showing me configuration of PHP4? Nice: in fact the only configured module on apache was that of PHP5, but it read the configuration of PHP4 and used that for some mysterious reason. And I wondered why the wrapper for sendmail I set up in sendmail_path did not work at all… this is quite mad.
Can I insist on the fact I hate PHP and all that?
Posted by mattia as apache, module, php, php4, php5 at 11:31 AM CEST
No Comments »
