Running a production web server with the following settings. Certain things will give the error "page cannot be displayed", and refresh will solve this. Here's the scenario

We were running Windows 2003 server and didnt have this issue (there are approximately 100k folders in the server root folder for different members), the problem with 2003 was that after a certain number of DB connections were made, it wasnt allowing anymore outgoing DB connections and gave failure.

Switched to 2000 because we found no solution for problem 1, and now the page cannot be displayed is coming up. Both servers are using the following versions of apache/php. I would appreciate any help anybody could provide. Thanks in advance!

Windows 2000 server SP4
Apache 2.0.54
PHP 5.0.5
Mysql 5.0.19 (separate machine running on linux)

    You really need to try to trace what's happening when people get this error:

    • MSIE does not provide useful error messages - switch to something which does, and/or use a network analyser such as Ethereal to see exactly what HTTP response is received in these cases (if any).

    If you're seeing the connection being reset with no HTTP response, one possiblity is that Apache is crashing. This should not happen, but it is difficult to debug. If Apache is crashing, it will show some message to that effect on its error log.

    So look at the Apache error log.

    If Apache crashes, it will automatically respawn new processes as necessary, so it won't cause the server to go down completely.

    I'm pretty sure that your OS can't be the cause of a problem connecting to MySQL. If something fails after a certain number of connections, it would suggest to me either the limits are set too low, or there was a resource leak:

    • Monitor the number of connections to MySQL
    • If it appears unreasonable, or increases without limit, consider refactoring your application to use fewer
    • Do not use persistent connections if they're a problem
    • (de) tune Apache to use fewer processes/threads so that it requires fewer connections
    • Tune MySQL so it supports more

    Mark

      MarkR wrote:

      - MSIE does not provide useful error messages - switch to something which does,

      Such as Firefox, with the livehttpheaders extension installed (just to suggest an example that I've found useful).

      MarkR wrote:

      - Monitor the number of connections to MySQL

      This is especially prone to cause problems if you use persistent database connections: idle server processes will maintain their connections at the expense of active processes that want to make new ones.

        well this problem ONLY happens in IE. It doesnt do it in firefox. I have the IE HTTP analyzer software i'm using to trace, but it doesnt give me any helpful information, just that it's trying to load a page that does exist, and it gives page cannot be displayed. The problem with the mysql connections giving problems does not happen at all on windows 2000, as soon as we made the switch that problem went away (same setup of php/apache/mysql) I even used the same php.ini and httpd.conf files on the new server as the old one!

          What do Apache's logs say about what's been happening? Do they say anything? And maybe try running the network analyser server-side.

            apache logs say nothing at all, no error or anything. same with php logs. no php errors

              9 days later

              I have a similiar if not the same problem.

              I have been developing an Intranet using:

              Apache v2.0.53 and PHP v5.0.4

              I believe the problem is related to the session handling, however it does seem to be IE specific. My development system is running XP with SP2. IE v6

              Clicking back from any of the pages sometimes results in The page cannot be displayed. This is always the case when clicking the Back button from a page that includes a form.

              Having spent sometime searching for a solution and also tried all the suggestions above, I'm still scratching my head.

              I turned on logging at debug level for Apache and restarted the service. Apart from the expected messages nothing was logged when the Page is failed to display. I personally do not believe that this is a problem with Apache as the browser is looking in its own cache for the page.

              I tried using Opera and it worked perfectly. Back and Forward work 100% as expected and correctly. Unfortunately we cannot use Opera as the Intranet contains both XML and OCX objects, neither of which are supported by Opera and I know that Firefox doesn't support OCX objects either.

              This would appear to be an IE cache problem, I think it may be solved by a setting in PHP for the session or cookie handling, but I am not certain what to do.

              Currently when I start the session I am doing the following:

              session_cache_limiter('private_no_expire');
              session_start();

              By default calling session_start without the session_cache_limiter() call results in headers being sent back to the client telling it that no cache control is required and that the session will expire in 180 minutes by default.

              The session_cache_limiter() overrides the default behaviour of session_start() and sends headers instructing the client not to use a public proxy cache, but to cache the content locally (privately), also the content will not expire.

                I found out what the problem was in my case, it wasn't Apache or PHP.

                Any page that contains a form which 'POSTS' data to the server causes the problem. MSIE does not add pages that are returned to a page as a result of a POST to the history. Using the GET method works fine as expected.

                The problem I have is that the GET method is limited to the size of the URL in that you cannot pass data greater than 256 bytes using the GET method, so what to do?

                This problem is limited to MSIE, Opera and Firefox work fine.

                  Correction: The length of a URL as defined by Microsoft in MSIE is 2048 characters, limited to ASCII data, so this might be useful.

                    2048 Characters is about 256 bytes (a character is 8 bits) 2048/8=256

                      lol, I know that, however it clearly states 'characters' not bits.

                      http://support.microsoft.com/default.aspx?scid=kb;EN-US;q208427

                      I've also now implemented and proven that the URL in MSIE is significantly longer than 256 bytes.

                      I've solved the problem now. If I want to use POST without messing up the navigation, then I must post to another page file altogether, this basically handles the posted data, copied it to a SESSION and then using the Header("Location: url") redirects back to the original page containing the form. This works well.

                        Write a Reply...