One of the things that drives the appeal of CGI scripts is the easy deployment story compared to, say, abunch of programs that implement web applications is the deploymentconfiguration problem . When you have a bunch ofapplications on the same machine (and using the same IP), you needa central web server to take incoming requests and dispatch themout to the appropriate individual web app (based on incoming hostand URL), and this central web server needs to be configured somehow.So how do you do this

Logjam covers two weaknesses in Diffie-Hellmankey exchanges: the ability to downgrade TLS sessions to use extremelyweak DH key exchanges, and the potential ability to break DH keyexchanges using common, known primes of 1024 bits and below.Logjam affects at least TLS, SSH, and IPSec's IKE protocol, all ofwhich I use. Since Logjam was announced I've been working on figuringout what I can and should do in reaction to it, which in part involvedlooking at my situation

I build a number of open source projects from source for variousreasons of my own, using clones of the upstream master repos. Withsome of them, I make changes for my own reasons, often changes Iwill never be attempting to push upstream . WheneverI make changes this way, I do not commit my changes to the repos .This is the case whether the project uses Git or Mercurial .

The plain and simple truth is that if you're going to perpetuallycarry modest changes to an upstream project that

(This is a grumble. You've been warned.)

A lot of open source projects are hosted on Github these days andmany of them prefer to get patch submissions in the form of Githubpull requests. On the one hand I admire Github for making the processof pull requests relatively painless for the maintainer(s) in mybrief experience. On the other hand, I don't find pull requests tobe very attractive from the other side, as a (potential) submitterof changes, and

One of the reasons that making bug reports is stressful for people who can do them well is that we'reaware of the quiet but very real social downside of submitting 'bad'bug reports in most contexts. One of the important practicalbenefits of making (good) bug reports is thatit builds up your good karma with the people behind whatever you'rereporting bugs on. This good karma makes it more likely that theywill take you seriously in the future, interact nicely with you,and perhaps even

One of the things that Amazon SES advertisesthat it (usually) does is that it scans the outgoing email thatpeople send through it to block spam. This sounds great and certainlyshould mean that Amazon SES emits very low levels of spam, right?Well, no, not so fast. Unfortunately, no outgoing mail scanning ona service like this can eliminate spam. All it can do is stop certainsorts of obvious spam. This is intrinsic in the definition of 'spam'and the limitations of what a

Today I reported a relatively small issue in the developmentversion of ZFS on Linux .In theory the way of open source development is that I should submita patch with my problem report, since this is a small and easilyfixed issue, and I suspect that a certain number of the usualsuspects would say that I'm lettingdown up my end of the open source social compact by not doing this(even though the ZoL developers did not ask me for this). Well,there's a problem with

This is kind of a warning story. It may not be true any more (Ibelieve that I ran into this back in 2013 , probablywith a 3.x version of mod_wsgi), but it's probably representativeof the kind of things that you can run into with Python web appsin an environment that mixes HTTP and HTTPS.

Once upon a time I tried converting my personal site from lighttpd plus a CGI based lashup for DWiki to Apache plus mod_wsgi serving DWiki as

Suppose that you have a WSGI application that's running under Apache,either directly as a CGI-BIN through some lashup or perhaps through an (old) version ofmod_wsgi (such as Django on an Ubuntu 12.04 host, which hasmod_wsgi version 3.3). Suppose that you want to know if you'rebeing invoked via a HTTPS URL, either for security purposes or foryour own internal reasons (for example, you might need separate page caches for HTTP