Posted on March 9th, 2009 by Neil Crosby. Filed under Uncategorized.
A week or so I wrote about running the W3C CSS Validator on the command-line. Yes, I know I said I didn’t need to run it as a website, but as it turns out the command-line version doesn’t seem to want to validate local files — only files being served from a web-server.
So, I went back to scratch and tried installing it on a web-server. Since my normal stack is Apache, MySQL and PHP I didn’t have any of the Java-based web-servers suggested by the W3C. My first attempt at getting the validator working was to use Jigsaw – the same web-server as the W3C uses to run their version on. Unfortunately, it didn’t work for me. Bugger.
So, I tried Tomcat. After following Basil Bourque’s instructions on Apache’s Tomcat wiki pages, I got Tomcat working. I then followed the rest of the CSS Validator installation instructions for Tomcat, and the validator worked in my browser. Excellent.
There was a fly in the ointment though. Whilst the validator worked in my browser, the same could not be said of my attempts to get it working via cURL calls from PHP using POST data. I was using the same code as I’d used to validate against the W3C’s HTML validator, so I knew that I was able to successfully push POST data across to servers. If I tried using GET requests to send the data to my local validator, then that worked. I verified the same thing was happening on the live CSS validator to make sure the problem wasn’t with my installation. I know you’re thinking “well, if GET worked, why not just make requests that way?” Unfortunately, I know that later I’ll be asking to validate much larger CSS rulesets — ones that will be far too large to fit on a URL. So, I needed to use POST.
After a fair bit of poking, I realised that the in-browser version of the CSS Validator was setting an
enc attribute value of
multipart/form-data on the form when it was uploading files or sending textual data. Conversely, it turns out that PHP was sending
application/x-www-form-urlencoded as the encoding type instead, and the W3C CSS Validator just isn’t set up to accept that. After a long time of trying to work out how to send things in
multipart/form-data format using PHP’s cURL functions, I happened upon a comment on PHP’s curl_setopt function which told me that if I gave PHP an array instead of a string it would automagically start using
multipart/form-data. As if by magic, my problem was solved.
My problems setting up my programmatic connection to the CSS Validator could easily have been solved by clearer documentation. Nowhere that I could find in the Validator’s documentation was there any mention of needing to make POST requests using
multipart/form-data. If this had been stated somewhere I would at least I have known the path I needed to be looking down. Likewise, lack of anything other than user-generated documentation for the PHP
CURLOPT_POSTFIELDS cURL option made life far more difficult than it should have been.
Still, in the end I have a local version of the W3C’s CSS validator running on my laptop, and I’m able to connect to it programmatically to run tests. Which is nice.
If you enjoyed this post, subscribe to The Code Train and read more when I write more.