Using SSL proxies with WWW::Mechanize - why doesn't my HTTPS proxy setting work? · 16 January 2008, 11:34

WWW::Mechanize is a sub-class of the tried and true LWP package. The problem is that LWP does not properly support SSL proxying for any web server other than Apache; it issues an GET request to the proxy with the full URL to be requested as opposed to doing a CONNECT through the proxy in question. While most of us do work with Apache, there are certainly times when we will be using other types of proxies; in this case I was coding a test that goes through a Bluecoat hardware proxy.

To have SSL proxies work properly with WWW::Mechanize on non-Apache platforms , just install Crypt::SSLeay (which also installs Net::SSL) and then set the proxy URL into the environment in a variable named HTTPS_PROXY. Example:


If you forget the port part Crypt::SSLeay will not accept the proxy setting, error will look like this:

500 no port given for proxy server NN.NN.NN.NN

To enable debugging output at the Crypt::SSLeay level, just set the environment variable HTTPS_DEBUG to 1


Finally, to turn on debugging output for LWP in a script at run time (i.e. via command line option) just call LWP::Debug::level(’+’), this will turn on all debug levels for LWP, very useful for troubleshooting LWP scripts.


— Max Schubert



Have the Spaghetti-ists All Migrated To PHP? · 12 August 2007, 17:32

I have been doing an increasing number of web site development jobs in PHP lately; the vast majority of the jobs have been enhancements to existing sites.

In the late 90’s I did a number of these kinds of jobs for perl/CGI driven sites. Many of them were written in such sloppy / unstructured perl code that I would either end up aborting the job (if the client did not have the money to pay for a full refactoring) or I would rewrite from scratch.

I thought that with PHP the situation might be different since so many things are so easy to do with PHP and surely developers would have more time to focus on program structure / design.

No. Same situation as with perl, I take over many spaghetti code projects and spend time either refactoring or rewriting from scratch. Often clients I work for are unpleasantly surprised to hear that the sites they had made will now cost them even more because the code was not written in a way that would make it easy for someone else to maintain / enhance.

This is not a rant about PHP developers in general; there are many PHP projects, especially on, that are very nicely written and that are easy to maintain and extend.

I guess the bottom line is that some things never change as much as I hope they would as software development ages and matures.

While it is nice to get paid to refactor (I really enjoy refactoring), I would prefer to spend my time developing new features and have refactoring just be a minor part of adding revenue-generating code to a site or project.

— Max Schubert



PHP: Often "lite" Is Just Right · 12 August 2007, 17:02

I have been a software developer for a little over ten years now; in that time I have written software using a wide variety of languages. With most languages, the key to fast success seems to be finding the right (i.e. most widely used, most idiomatic) frameworks or libraries to use.

I find that with PHP I am often developing on memory or I/O starved platforms; for these situations the “right” frameworks tend to be too memory and/or CPU intensive for the hardware (or VPS) that is hosting the application. More often than not in these situations I use an Extreme-style of JIT infrastructure development approach.

For example:

As a project / site grows I add to these libraries to fit the needs of the site. If it gets large enough to warrant more beefy hardware, RAM, and disks, then I look at converting to PEAR libraries and larger frameworks, which tends to be fairly easy as I already have class wrappers for most functionality in place at that point.

— Max Schubert



PHP 5.2.3: an old bug rears its' head · 10 August 2007, 14:25

Compiling PHP 5.2.3 on Solaris 10, ran into a PHP configure script bug that perplexed me for a few days. PHP would compile fine, but ‘make test’ would result in a segfault. Stack trace shows a date / timezone function


being called, followed by memcpy() from libc, followed by a segmentation fault and core dump.

The bug is filed here

for the Wind River OS, but the problem and solution are the same for Solaris 10.

Upgrading to 5.24RC5 works as well as that build does not have the same configure / WORDS_BIGENDIAN problem.

— Max Schubert