Moodle
  1. Moodle
  2. MDL-28382

YUI: yui_combo.php triggers 404 error on old or misconfigured IIS servers

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0, 2.1, 2.2
    • Fix Version/s: 2.0.5, 2.1.2
    • Component/s: General, Navigation
    • Labels:
      None
    • Environment:
      Fully dedicated server 2.8GHz Intel Dual Core, 4GB RAM
      Windows Server 2008 (x64) Web Edition, IIS7, PHP 5.3.6, MySQL 5.5.14
      Firefox 5.0 (x86 en-GB), Firebug, FlashFirebug
      Moodle 2.1+ (Build 20110713)
    • Database:
      MySQL
    • Testing Instructions:
      Hide

      1/ enable you combo loading (enabled by default)
      2/ view page source and copy yui combo loader url (fix amp;s)
      3/ clear browser cache
      4/ access the conbo url directly
      5/ on some servers the QUERY_STRING is used on others error message is printed

      Show
      1/ enable you combo loading (enabled by default) 2/ view page source and copy yui combo loader url (fix amp;s) 3/ clear browser cache 4/ access the conbo url directly 5/ on some servers the QUERY_STRING is used on others error message is printed
    • Workaround:
      Hide

      1/ disable combo loading
      2/ or fix your IIS configuration (the default fastcgi PHP 5.3 install from MS works fine)

      Show
      1/ disable combo loading 2/ or fix your IIS configuration (the default fastcgi PHP 5.3 install from MS works fine)
    • Affected Branches:
      MOODLE_20_STABLE, MOODLE_21_STABLE, MOODLE_22_STABLE
    • Fixed Branches:
      MOODLE_20_STABLE, MOODLE_21_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      w31_MDL-28382_m22_iis
    • Rank:
      18110

      Description

      yui_combo.php returns a 404 (file-not-found) error from line 32, due $parts variable being empty.
      This may arise from Firefox/Firebug reporting "Failed to load source for: "<web site URL>, although the Moodle home page appears to fully load.
      This issue was previously raised on 13th July in the forum at http://moodle.org/mod/forum/discuss.php?d=181123&mode=1
      PROBLEM:
      After administrator login, first level expandable menu administration items (>) are inactive, e.g.: Site pages, Reports, My profile, Front page settings, My profile settings, Site administration. Some items/pages are accessible with the Search function. When a page is found via Search, first-level menu items (>) are inactive.
      On the first installation on this server (apparently successful, but actually not), when attempting to set up a SCORM activity, the editing page "could not find" the Repository plugin although the SCORM editing page otherwise appeared to be fully formed (this was the trigger for exploring this issue). This behaviour has not been examined on more recent installations, but is presumably the same as nothing else has changed.
      COMMENT:
      This problem has PERSISTED:
      1. Throughout 5 installations of Build 20110701 and Build 20110713 on this server, before giving up on bug tracing (my knowledge of YUI and the means of generating its parameters is limited).
      2. The server was then REBUILT (ie the entire OS was reinstalled), to start with a virgin environment.
      3. On installing Moodle, the Server checks page reported "Your server environment meets all minimum requirements".
      4. Extensions for openssl and intl were added
      5. On completion of installation, all items (14 pages - 170?) reported "Success". This is attached as a PDF.
      NOTES:
      1. Moodle 2.1 (Build 20110707) was installed without problem on a local test computer running Vista Business. I am quite happy with the local (Vista) installation. This issue has arisen when trying to set up a production server.
      2. While my testing is with Firefox/Firebug, the same behaviour is evident with IE9.
      3. Due to this problem I can't set up an administrator account for deeper review of this site, or change my operational admin password. If it is really necessary to go beyond the login page, or access the server itself, please email me.
      4. This issue has been reported previously in MDL-25867 and before, with a "Cannot reproduce" resolution.

        Issue Links

          Activity

          Hide
          Ian Wright added a comment -

          For me, the priority is "Show-stopper" - I guess "Minor" was assigned as the "Workaround" field contains text.

          Show
          Ian Wright added a comment - For me, the priority is "Show-stopper" - I guess "Minor" was assigned as the "Workaround" field contains text.
          Hide
          Ian Wright added a comment -

          I notice that Firebug Script trace for my working local installation displays "Failed to load source for: http://localhost/", so that's evidently not a cause/factor in this issue as suspected in line 2 of the issue description.

          Show
          Ian Wright added a comment - I notice that Firebug Script trace for my working local installation displays "Failed to load source for: http://localhost/ ", so that's evidently not a cause/factor in this issue as suspected in line 2 of the issue description.
          Hide
          Mary Evans added a comment -

          Pete,
          I hope you don't mind me assigning this to you, but this problem seems to be an issue which might have repercussions for Moodle 2.x (for some Moodle instalations)

          For more information please see Forum posts on this issue here...
          http://moodle.org/mod/forum/discuss.php?d=182018
          and here...
          http://moodle.org/mod/forum/discuss.php?d=181123

          Thanks
          Mary

          Show
          Mary Evans added a comment - Pete, I hope you don't mind me assigning this to you, but this problem seems to be an issue which might have repercussions for Moodle 2.x (for some Moodle instalations) For more information please see Forum posts on this issue here... http://moodle.org/mod/forum/discuss.php?d=182018 and here... http://moodle.org/mod/forum/discuss.php?d=181123 Thanks Mary
          Hide
          Mary Evans added a comment -

          Hi Sam, I've just added you to watch this tracker with the view to finding a solution to this problem.
          Cheers
          Mary

          Show
          Mary Evans added a comment - Hi Sam, I've just added you to watch this tracker with the view to finding a solution to this problem. Cheers Mary
          Hide
          Petr Škoda added a comment -

          Hello, please do not assign any bugs to me, I will not have time to work on this in the near future. I assign bugs to myself only when I am really planning to work on it in the next 2 weeks.

          As a workaround you can try to disable the yui combo loading in the admin settings ($CFG->yuicomboloading = false

          I can not reproduce/diagnose this problem on my test servers, sorry. Could it be IIS specific problem or just a configuration issue?

          Show
          Petr Škoda added a comment - Hello, please do not assign any bugs to me, I will not have time to work on this in the near future. I assign bugs to myself only when I am really planning to work on it in the next 2 weeks. As a workaround you can try to disable the yui combo loading in the admin settings ($CFG->yuicomboloading = false I can not reproduce/diagnose this problem on my test servers, sorry. Could it be IIS specific problem or just a configuration issue?
          Hide
          Petr Škoda added a comment -

          In any case when diagnosing problems on the IIS server you must disable error pages in the IIS configuration because it hides all meaningful debug messages from Moodle and PHP itself. The you should enable debug from config.php, it is not enough to do it from database because some scripts do not fetch config from DB at all:

          @error_reporting(1023);
          @ini_set('display_errors', '1');
          $CFG->debug = 38911;
          $CFG->debugdisplay = true;
          

          After you do these two changes the yui_combo.php will complain loudly and tell you exactly what is going on.

          Show
          Petr Škoda added a comment - In any case when diagnosing problems on the IIS server you must disable error pages in the IIS configuration because it hides all meaningful debug messages from Moodle and PHP itself. The you should enable debug from config.php, it is not enough to do it from database because some scripts do not fetch config from DB at all: @error_reporting(1023); @ini_set('display_errors', '1'); $CFG->debug = 38911; $CFG->debugdisplay = true ; After you do these two changes the yui_combo.php will complain loudly and tell you exactly what is going on.
          Hide
          Ryan Smith added a comment -

          Since you are on IIS I assume you are using FastCGI with the NTS version of PHP.

          Did you set cgi.fix_pathinfo=1 in your php.ini? I believe that is required for IIS. Also, be sure to run Wincache...it tremendously improves your website speed.

          Show
          Ryan Smith added a comment - Since you are on IIS I assume you are using FastCGI with the NTS version of PHP. Did you set cgi.fix_pathinfo=1 in your php.ini? I believe that is required for IIS. Also, be sure to run Wincache...it tremendously improves your website speed.
          Hide
          Ian Wright added a comment - - edited

          Thank you , Petr.
          However I added the error/debug elements to config.php, and there was zero change from previous behaviour. That is, no debug or error messages, and no entries in the php error log (which exists, but is empty). I've checked the php.ini error settings and anything at all should be displayed and logged.

          For interest I commented out the header line of combo_not_found() in yui_combo.php, just to see what would happen:

          function combo_not_found()

          { // header('HTTP/1.0 404 not found'); die('Combo resource not found, sorry.'); }

          This generated two new errors in Firebug; both with the text 'missing ; before statement' followed by the text 'Combo resource not found, sorry.' as per the die() text in combo_not_found(). The error source links for the errors were different; one pointing to the 3.2.0/build debug files, and the other pointing to the 2.8.2/build debug files.

          Because Firebug threw the text from combo_not_found() does indicate that the 404 error is generated by the combo_not_found() function, and not that the files could not be found. But I don't know where the missing semicolon is...

          Show
          Ian Wright added a comment - - edited Thank you , Petr. However I added the error/debug elements to config.php, and there was zero change from previous behaviour. That is, no debug or error messages, and no entries in the php error log (which exists, but is empty). I've checked the php.ini error settings and anything at all should be displayed and logged. For interest I commented out the header line of combo_not_found() in yui_combo.php, just to see what would happen: function combo_not_found() { // header('HTTP/1.0 404 not found'); die('Combo resource not found, sorry.'); } This generated two new errors in Firebug; both with the text 'missing ; before statement' followed by the text 'Combo resource not found, sorry.' as per the die() text in combo_not_found(). The error source links for the errors were different; one pointing to the 3.2.0/build debug files, and the other pointing to the 2.8.2/build debug files. Because Firebug threw the text from combo_not_found() does indicate that the 404 error is generated by the combo_not_found() function, and not that the files could not be found. But I don't know where the missing semicolon is...
          Hide
          Ian Wright added a comment -

          Ryan, thank you. Yes, FastCGI non-threadsafe NTS PHP. cgi.fix_pathinfo was not explicitly set, but default is 1. fastcgi.impersonate is also set to 1 (for IIS).
          Thanks for the heads-up on Wincache (although I'll leave that until this problem is sorted).

          Show
          Ian Wright added a comment - Ryan, thank you. Yes, FastCGI non-threadsafe NTS PHP. cgi.fix_pathinfo was not explicitly set, but default is 1. fastcgi.impersonate is also set to 1 (for IIS). Thanks for the heads-up on Wincache (although I'll leave that until this problem is sorted).
          Hide
          Ian Wright added a comment -

          HAVE I GOT IT?
          yui_combo.php function combo_params()
          -------------------------------------
          A check of $_SERVER['REQUEST_URI'] produced a string that did not contain a '?', so the explode('?',$_SERVER['REQUEST_URI']) produced an empty return, and combo_not_found() threw a 404 error.
          By commenting out that part of combo_params(), and just looking at $_SERVER['QUERY_STRING], the Moodle installation appears to work.
          No detailed test yet, but all the main administrative menus appear to work, and there's no YUI undefined error.

          Show
          Ian Wright added a comment - HAVE I GOT IT? yui_combo.php function combo_params() ------------------------------------- A check of $_SERVER ['REQUEST_URI'] produced a string that did not contain a '?', so the explode('?',$_SERVER ['REQUEST_URI'] ) produced an empty return, and combo_not_found() threw a 404 error. By commenting out that part of combo_params(), and just looking at $_SERVER ['QUERY_STRING] , the Moodle installation appears to work. No detailed test yet, but all the main administrative menus appear to work, and there's no YUI undefined error.
          Hide
          Petr Škoda added a comment -

          right, the REQUEST_URI is known to be different in IISE, I suppose this is the cause of the problem.

          Show
          Petr Škoda added a comment - right, the REQUEST_URI is known to be different in IISE, I suppose this is the cause of the problem.
          Hide
          Ian Wright added a comment - - edited

          The generation of a 404 error probably seemed at the time like a good way to deal with missing YUI parameters, but I'd like to suggest some more relevant error handling to cater for servers other than Apache.
          After all, PHP documentation on $_SERVER does warn "There is no guarantee that every web server will provide any of these; servers may omit some, or provide others not listed here."
          I'm somewhat bemused by the thought that crowds of IIS users have not been gathering with this problem - I can't be the only IIS7 user - perhaps many recent installation issue posts have this at their core?

          Show
          Ian Wright added a comment - - edited The generation of a 404 error probably seemed at the time like a good way to deal with missing YUI parameters, but I'd like to suggest some more relevant error handling to cater for servers other than Apache. After all, PHP documentation on $_SERVER does warn "There is no guarantee that every web server will provide any of these; servers may omit some, or provide others not listed here." I'm somewhat bemused by the thought that crowds of IIS users have not been gathering with this problem - I can't be the only IIS7 user - perhaps many recent installation issue posts have this at their core?
          Hide
          Ian Wright added a comment -

          As noted by Matteo Scaramuccio, http://support.microsoft.com/kb/954946 is relevant (Title: FIX: A PHP application that depends on the REQUEST_URI server variable may fail when you run the PHP application in IIS 7.0). But IMO this (and possible future similar server behaviours) should not cause Moodle to fail in critical areas such as YUI

          Show
          Ian Wright added a comment - As noted by Matteo Scaramuccio, http://support.microsoft.com/kb/954946 is relevant (Title: FIX: A PHP application that depends on the REQUEST_URI server variable may fail when you run the PHP application in IIS 7.0). But IMO this (and possible future similar server behaviours) should not cause Moodle to fail in critical areas such as YUI
          Hide
          Petr Škoda added a comment -

          To summarise this:
          1/ fresh new installs using MS installers work fine for me
          2/ there is a simple workaround - disable combo loading
          3/ after my patch the problem is either fixed or combo loader prints meaningful error hinting at possible solution

          Thanks for the report.

          Show
          Petr Škoda added a comment - To summarise this: 1/ fresh new installs using MS installers work fine for me 2/ there is a simple workaround - disable combo loading 3/ after my patch the problem is either fixed or combo loader prints meaningful error hinting at possible solution Thanks for the report.
          Hide
          Mary Evans added a comment -

          Thank you Petr
          I am so pleased some good has come out of this Tracker Issue.

          Mary

          Show
          Mary Evans added a comment - Thank you Petr I am so pleased some good has come out of this Tracker Issue. Mary
          Hide
          Ian Wright added a comment -

          Thank you, Petr.
          As every magician knows, a bit of mis-direction will fool most people all of the time.
          Moodle is so complex now that we users need lots of meaningful error hinting.
          (And it's a pity Microsoft haven't included their IIS7 hotfix in their endless stream of updates!)

          Show
          Ian Wright added a comment - Thank you, Petr. As every magician knows, a bit of mis-direction will fool most people all of the time. Moodle is so complex now that we users need lots of meaningful error hinting. (And it's a pity Microsoft haven't included their IIS7 hotfix in their endless stream of updates!)
          Hide
          Sam Hemelryk added a comment -

          Wow more great detective work! thanks Petr, this has been integrated now.

          Show
          Sam Hemelryk added a comment - Wow more great detective work! thanks Petr, this has been integrated now.
          Hide
          Rajesh Taneja added a comment -

          Works Great...
          Thanks for fixing this Petr

          Show
          Rajesh Taneja added a comment - Works Great... Thanks for fixing this Petr
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Sent upstream and closing, many thanks!

          Show
          Eloy Lafuente (stronk7) added a comment - Sent upstream and closing, many thanks!

            People

            • Votes:
              2 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: