Malformed POST request made to an absolute url with Flash

Sometimes you encounter bugs that smacks you in the face with their strangeness. And even when you defeated them you still have this sour taste of puzzlement.

I encountered one of them today.

While testing in a local environment and doing POST requests from Flash to a distant cake app, I could get the request just fine.

But when uploading the SWF on the server and embedding it in a Facebook App Iframe, the POST data seemed corrupted and I couldn't get it.

Replacing the distant POST call to a local one (removing the whole http:// part) fixed this strange bug.

So we ended by adding a check to see if we were online or local and make an absolute or relative call depending on the environment.

So far, no more issues.

Going to parent folder in Windows 7 Explorer

At first I thought I missed an option somewhere, but now I have to admit : Microsoft removes the "Go to parent folder" button in the Windows 7 version of Explorer.

I like their new implementation of folder path, but a fast click to go up one level, positionned in a consistent way in the UI is a plus.

After some research I found the Alt + Up keyboard shortcut to achieve the same result, but while navigating through the explorer, I always am using my mouse. Switching from mouse to keyboard is tedious, so I hunt for another solution.

I finally installed ClassicShellthat adds the missing button as well as some other minor cosmetics changes.

Protecting a directory using HTTP Auth on Dreamhost with cakePHP

One can protect the browsing of a special directory with a simple set of login/password by using appropriate .htaccess/.htpasswd files.

The classic way

Just create an .htaccess in the directory you want to protect with the following lines :

AuthName "Restricted Access"
AuthType Basic
AuthUserFile /full/path/to/your/.htpasswd
<Limit GET POST PUT>
Require valid-user
</Limit>

And to create the .htpasswd file, run the following command :

htpasswd -c /full/path/to/your/.htpasswd username

The -c modifier will create the file, omit it if you only want to add a new user. Also change the path to your .htpasswd file (moving it out of the webdir could be a good idea) and change usernameto any login you want.

You'll then be prompted to enter the password (twice) and your file will be generated.

cakePHP and Dreamhost fixed

I had an issue when protecting a folder in my app/webroot/folder on Dreamhost. I'm not sure it is completly cake related nor Dreamhost related but the two together made it quite hard to debug.

Anyway, it appears that when issuing an HTTP Auth, Dreamhost redirect to a file named /failed_auth.html (this is the file you're supposed to see when your Auth fails, obviously).

But as I didn't have such a file in my app, everytime I tried to access my protected dir, I got my custom 404 error page.

To finally fix that, all I had to do was to create a real failed_auth.html page, or in my case, create a Route that redirect failed_auth.html to a custom failed auth page.

I guess just dropping a failed_auth.html file in app/webroot/could have done the trick too.

Strange requestAction bug changing the page Content-Type

Today, I thought my current project was finished. But I had this bug report in my tracker from one of the beta-tester telling me that one of the page wasn't rendered properly.

It says that the code source was displayed on screen instead of being rendered as HTML. And only on Firefox.

And if that wasn't odd enough, even with the plethora of Firefox versions I got, I couldn't reproduce the bug on my side.

Turning off the debugger to debug

Then I had an idea. I turned off the debug mode, and was then able to reproduce the infamous bug.

As I initially supposed, there was something wrong with the Content-Type header. The Firebug Net Panel told me that it was set as text/plain while the developer toolbar insisted that it was text/html.

After some digging in my own code, I found the culprit. A requestAction() call I made as part of an update process. This requestActionwas targeted at a .txt file.

I played a little with the debug value and found that for any value above 2, everything was working correctly, but if I set my value below that threshold, my whole view will get displayed as text/plain.

I couldn't quite explain why a debug value will have anything to with the view rendering. I even disabled the Debug Kit component, just to be sure.

Digging into cake world

And then I decided to follow the dispatch trace to find where the debug value was being used. After a long journey, I got to the respondAsmethod of the RequestHandlercomponent.

And specifically, to that part :

if (Configure::read() < 2 && !defined('CAKEPHP_SHELL')) {
  $this->_header($header);
}

Ok, so there was my debug value. Exactly the code reponsible for my symptoms. Well, I still don't understand WHY someone wanted to add an header based on the debug value, but I could easily understand HOW it made my view that ugly.

The requestActionwas being dispatched all along the way to its final action, firing the RequestHandlercomponent on its way. Its extension being .txt, RequestHandlerwill fire its respondAs method and set the appropriate header.

Unfortunatly, setting such an header in a requestActionwasn't useful for the request, and additionnaly, it was messing with the primary view dispatch path.

Solution

Ireported the bug hoping for a fix in a future version. For the time being, I manually set the debug to 2 before calling my requestAction, and set it back to its previous value after in my app.

And for why it was only buggy on Firefox, it was caused by a double header definition. A first header was telling text/plain and a second onetext/html. I guess Firefox uses the first one while other browsers the last. This is what made Firebug and the Developer Toolbar return different results too.

Apache rewrite_mod small tip

Did you know that when debugging RewriteRules, instead of commenting/uncommenting each line, you can simply make RewriteEngine On / RewriteEngine Off all along your code ?

I didn't, and now that I do it seems so obvious I don't believe I've never thought of that before...