When/why would Chrome get 500 error on localhost but load OK from 127.0.0.1, while Firefox loads both?

Question

So when/why would Chrome fail on localhost but load OK from 127.0.0.1?

PHP MySQL IIS Windows 10 was running just fine. phpMyAdmin suggested updating. So, renamed working directories to -old. Attempted to update phpMyAdmin and it needed to update PHP as well. Had issues (deprecated functions) so returned to using the original directories. Screwed something up I can't identify.

Yikes! Chrome will no longer load localhost/phpmyadmin/index.php Error 500: The localhost page isn’t working. localhost is currently unable to handle this request.

NOPE! NOT a server error, because:

Firefox 50.1.0 DOES load phpMyAdmin index page correctly and run queries

Chrome 55.0.2883.87 m DOES load http://127.0.0.1/phpmyadmin/index.php correctly and run queries

Chrome also runs my own php application scripts that use MySQL just fine.

I given the directory phpMyAdmin directory every permission from any user including IIS_IUSRS. But since access Chrome from 127.0.0.1 works fine and Firefox works from localhost, I don't expect it to be a file permissions issue.

Following advice I found elsewhere, I've been to chrome://flag and reset to defaults.

I have cleared Chrome cache from 4 weeks before, up to now.

I hesitate to clear cookies in case of some I may need to keep to be recognized on other certain sites, etc. Not sure how to view and delete only phpMyAdmin related ones, if applicable.

I "think" I left config.inc.ini unchanged from when it was working. phpMyAdmin is all in wwwroot of inetpub.

Stop and Start MySQL service. Browser ctrl-shift-R reload. Fruitless. I suppose I can bookmark 127.0.0.1 instead, but I'd rather learn what's going on.

So what changed to cause my Chrome to now treat localhost (fails to load) differently from 127.0.0.1 (loads just fine)?

Solution

A 500 Internal Server Error indicates that Chrome does try to load the page and even gets a server response (being the 500 error). So, the server fails. It probably has some logs?

As cookies are stored per (sub-)domain, and localhost and 127.0.0.1 are different domains, my bet is that Chrome has an old cookie for localhost, which has not yet expired, but is somehow no longer valid.

Even if PHP and phpMyAdmin are backwards compatible (so would handle differences after upgrades), the troublesome cookie might have been created while you were testing the new PHP and new phpMyAdmin. And now that you reverted the upgrade either PHP or myPhpAdmin does not understand the newer format of the cookie or a session it refers to.

• For sessions, a browser's session cookie holds an id which on the server refers to "serialized" PHP objects. So, maybe the serialization format has changed in newer versions of PHP, and the old PHP does not know how to handle the newer format.

• For other cookies, maybe phpMyAdmin has stored serialized objects in the cookie directly, or in its database, or simply expects different data than it finds in the cookie.

To test the above:

1. To see if a session cookie is the culprit: restart Chrome and try again.

2. To see if a regular cookie is causing this without wiping it yet: try an incognito session, which does not send existing cookies to the server. If that works: clear the localhost cookies.

If this does not work, then you need to find the 500 error in the server's log.

Comments

[SadJustSad]

You solved it ! Thank you. Details : By the time I saw the reply, I had already restarted Chrome (and the computer) several times. The problem seemed to remain with only phpMyAdmin. I found only years-old logs; nothing anywhere near current. But the suggested incognito window loaded just fine. I followed the instructions to clear specifically the phpMyAdmin cookies (2) under localhost. Cut url from incognito window, closed it, pasted into normal window. Momentary shock at 500 error (cache?) which disappeared on refresh window. Back to normal. Thanks again.

[Dave E]

@SadJustSad So why haven't you marked this as the answer?