| 11:21 pm on May 30, 2014 (gmt 0)|
I get random 500 errors in GWT that are fine when I try them - I just rack it up to maybe some kind of temporary glitch when Gbot tried to access the page. If they persist, then I investigate to see if there's a server problem. But it's not unheard of to see a one off from time to time.
| 11:42 pm on May 30, 2014 (gmt 0)|
You could take a look at your server logs for the time and day in question, to see what requests and responses were being sent and returned. You might spot something simple to fix that takes care of it. Or not - some processes don't produce http requests, such as js or php functions. Doesn't hurt to look.
| 7:55 pm on May 31, 2014 (gmt 0)|
Thanks... our server logs for the site are pretty big. I guess I'll wait until I happen to be up after a new log starts for a day and then try to reproduce the error from WMT.. and if I can, then download the log file while it's small enough to be manageable for me to download open and search.
| 9:06 pm on May 31, 2014 (gmt 0)|
Some servers will have a separate log you can download that rolls over to a new log at server midnight - OR you could try using a tool to record headers and look at just one or two visits separately. Firefox browser has the LiveHeaders plugin that is handy for that kind of thing.
| 3:14 pm on Jun 1, 2014 (gmt 0)|
Our logs do rollover at midnight.. and it's those individual logs that are really big.. which is why I need to try to recreate the error just after the log rolls over.
I don't understand what you mean by looking at headers. I pretty much only know enough tech stuff to do really basic things and be able to talk with and understand (sort of) the programmers we outsource work to.
| 4:23 pm on Jun 1, 2014 (gmt 0)|
Firefox Live Headers captures the requests and responses between your browser and the server so you can see exactly what browser request is returning the "500" response.
This is an edited copy of a live header request/response - lots of blah-blah in there, but you can see that the broswer (via the html page) is asking for an image in the page, named "newdesign.png":
and the server receives that request and returns a "200" (found) response:
HTTP/1.1 200 OK
GET /newdesign.png HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:21.0) Gecko/20100101 Firefox/29.0
Accept-Encoding: gzip, deflate
Cookie: __utma=1234567890.123456789.123456789.1234567890.123456789.5; __atuvc=1234%5678%
HTTP/1.1 200 OK
Date: Tue, 07 May 2014 02:03:40 GMT
Last-Modified: Tue, 02 Jun 2009 17:43:58 GMT
Keep-Alive: timeout=5, max=75
For your test, you would save the live headers (as a .txt file) from opening the URL that gives the error, and look for the request that returns the "500" (config) error to see what needs to be fixed.
It might look like gobbledygook, but the part you're interested is pretty simple. And it lets you run your testing at your convenience.
| 5:44 pm on Jun 1, 2014 (gmt 0)|
Thanks :) I'll get the add on.