As a WebGUI developer, I’m used to the idea that the open source content management system is constantly evolving and improving. Even freshmeat.net has acknowledged this now in their recognition of WebGUI as the top project in their “vitality” category.
This knowledge of WebGUI’s active development may cause one to judge past versions, even stable releases, as somehow functionally incomplete or worse, buggy. This premature verdict is unfair—to both WebGUI and the jury. Recently while helping out a client, I caught myself in this bad habit of convicting WebGUI before gathering and reviewing all the evidence.
An emailed link similar to the following was misbehaving:
http://a-c-m-e.com?op=auth;method=emailResetPassword;token=a12bC3
Once clicked on, the site would percent-encode the semicolons:
https://a-c-m-e.com/?op=auth%3Bmethod=emailResetPassword%3Btoken=a12bC3
Admittedly, the source of the problem is fairly obvious to the technically sharp-eyed among you. However, in my evening rush, I compared the two links not side-by-side, but by switching back and forth between email and browser.
That missing PATH_INFO in the original URL just did not look correct to me. To explain why I thought this way, let’s review browser behavior. When visiting the home page of a site for the first time, users will most likely type only the domain name, omitting other characters required by Web standards:
a-c-m-e.com
Conveniently, the browser will automatically add the HTTP protocol prefix and the default root PATH_INFO:
http://a-c-m-e.com/
In this case, I assumed the browser not only added that default root PATH_INFO—as it did—but in its confusion over a missing PATH_INFO, also percent-encoded the request parameters. I blamed the browser. I blamed the email. I blamed WebGUI for not adding the default root PATH_INFO when generating the email.
I was ready to patch WebGUI.
After querying one of our in-house experts—thanks, Graham!—I realized my mistake. The browser was not rewriting the URL request parameters: The server was. What should’ve clued me in was the protocol change from HTTP to HTTPS, which I did not immediately notice. Thanks to Graham, I avoided patching an imaginary bug in WebGUI and annoying every WebGUI user in the world.
Further investigation revealed a modproxy configuration directive as the guilty culprit:
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L]
The fix is simple enough:
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,NE,R,L]
The [NE] flag instructs Apache mod_rewrite to Not Encode request parameters.
The moral of my story is this: Don’t start solving problems by blaming WebGUI. I’m sure I’ll forget it in my next problem-solving session, but hopefully you won’t. You’ll be thankful for not having to patch an already solid system, even though you have all the freedom and resources to do so.
