YSlow (Firebug plugin) forces submitted forms to serve cached pages

I did a little more investigation... The form submission goes through fine all the way to 'header' call in drupal_goto... However then seems like the redirect fails, with watchdog log getting these two messages:

include_once(./themes/engines/phptemplate/phptemplate.engine) [<a href='function.include-once'>function.include-once</a>]: failed to open stream: No such file or directory in /var/drupal/drupal-5.2/includes/theme.inc on line 78.

include_once() [<a href='function.include'>function.include</a>]: Failed opening './themes/engines/phptemplate/phptemplate.engine' for inclusion (include_path='.:/usr/share/pear') in /var/drupal/drupal-5.2/includes/theme.inc on line 78.

I googled this error and found a similar issue here (http://drupal.org/node/131032) about Devel printing no output. The solution in that issue was to try a default theme. However I tried Garland and this did not fix the problem for me.

What could be the root cause of the error I am getting?

Yet another datapoint... I tried the same test on a Drupal install with Garland theme and most modules turned off. The reload of submitted values worked OK, but the watchdog log contains the same errors... Go figure.

This seems to be the problem with all other forms that must reload themselves after saving... Help!

With more research, I think I found the root cause. First the diagnositcs:

1) Watchdog entries are thrown by devel_shutdown function and go away when I turn off devel timer/query display
2) To check whether the new pages are generated, I added the following line to the top of index.php

print 'index.php: GETCWD = '.getcwd().' TIME = '.gmdate('Y-m-d H:i:s', time());

3) Every time the problem occured (form returns old values), the page always had the old timestamp.

This means the problem is browser caching. I tried this in IE 7 and FF 2 with and without Firebug. The problem only showed up in FF with Firebug. Presumably when drupal_goto sets header location the same as existing page Firebug destroys the redirect, while IE and FF follow it fine.

When Firebug is disabled the problem goes away. Filing an issue for Firebug developers.

Final post! Looks like the cause was not even Firebug itself but YSlow plugin http://developer.yahoo.com/yslow/

YSlow breaks page reload when set on Autorun, which is not even a very useful option anyways. Turning off Autorun solves the problem, so at this point this is just the documentation matter. Updated bug report on Firebug here:
http://code.google.com/p/fbug/issues/detail?id=273&start=200

There is still need to fix watchdog messages, not related to the original bug: http://drupal.org/node/172263

The issue should be obsolete by now...