Month: June 2010

CGI Trailing Path Information

Another one I couldn’t search up information on, so putting it here for posterity.

I was playing with an elderly blogging platform called Blosxom. It’s really simple to use, although that, combined with its age, means it’s not up to the current status quo. Regardless, I found it fun to play with. Plus, it’s written in Perl, and everything else is PHP these days, so it was a nice novelty.

Now, one of the things it expects (as does the rest of the internet, apparently), is that the CGI file may be treated as an application, folder, or directory on the web. Like this:

http://example.com/blosxom.cgi/2010/06/28#Post

Now, the script itself is the cgi file, a file called blosxom.cgi in the root of my server. As you can see, it looks like a directory in that location, and according to the Internet, that feature should work, passing any “trailing pathname information” (as Apache calls it) to the script via the PATH_INFO environment variable.

Apache didn’t think so.

Now, attempts to google for “apache trailing slashes” or “apache cgi trailing slashes” or anything like that ended up fruitless. It shames me to say I spent over an hour investigating things like ExecCGI, mod-rewrite stuff, and all manner of other things to try to find out why that feature wasn’t working for me.

Eventually, I did what I probably should’ve done an hour before, and looked at the server error logs. Yes, they existed and were visible. I didn’t think that particular host would let me see them — it’s a free host — but I was wrong, and they surprised me yet again.

So, here’s the key: the host had switched off the AcceptPathInfo directive. Ordinarily, that’s left to the handler concerned (CGI, PHP etc.) to decide, which explains the ubiquity of the “on” setting, and the lack of anyone complaining when it’s switched off in various places I looked.

So there you have it, folks. If your CGI scripts don’t work when you have trailing slashes or trailing path info after the script’s name, don’t get lost in RewriteRules – have a look for AcceptPathInfo.

SIPDroid Locking up Audio

When running SIPDroid on my XPeria X10 (although I’ve heard of other Android phones doing the same), it appears to make one call, then after hanging up, it, well, doesn’t hang up. In short, SIPDroid seems to lock the call in place, where it continues even though it’s ended.

Not only that, but the rest of the audio on the phone stops too, until a reboot of the phone.

Here’s how I fixed it:

  • Make a call.
  • Note the codec it uses (shown under the call box). It will be something like “PCMA (64kbit)” or “PCMU (64kbit)” or something else technical looking[1].
  • Assuming the call fails (which is, after all, why you’re here!) go into the settings, choose “Audio Codecs”, and disable the codec you just noted. In my case, I set “PCMU (64kbit)” to “Never”
  • This is the annoying bit. You’ll probably have to reboot the phone if SIPDroid won’t let you make another call.
  • Once you’re back in, make another call, and note the codec. If you’re lucky, you’ll have a successful call, and no lockup. Success!
  • …on the other hand, if you’re like me, you’ll have to repeat this process until it works. For me, I hit GSM before it worked.

Of course, there are other known issues at the moment, including one-way audio, issues with registering with the VOIP server, and so on. I didn’t have these issues, so if you are, you’ll have to look elsewhere I’m afraid!

[1] …where “technical looking” means stuff like G722 HD Voice (64kbit), silk24, silk16, silk8, speex, GSM, BV16, or other supported audio codecs.

(Writing this here because I haven’t seen anything similar after much googling. Hopefully it’ll help someone!)