Attached is a patch that will add an explanation of response codes to the broken links report. This will give less tech-savvy users an idea of what each response code means.

The following text will be added to the bottom of the report:

Common status codes:
200 - the server successfully returned the page
404 - the requested page doesn't exist
503 - the server is temporarily unavailable

General code categories:
2xx codes are successful
3xx codes are redirects
4xx codes are request errors (i.e. bad request, forbidden, not found)
5xx codes are server errors (i.e. internal server error, service unavailable, etc.)

CommentFileSizeAuthor
linkchecker.pages_.inc_.patch1.33 KBcaesius

Comments

caesius’s picture

caesius commented
Version: 7.x-1.0-beta1 » 7.x-1.x-dev
hass’s picture

hass commented

Before we can are able to commit new patches we need to fix #1441574: Port D6 access bypass bugfixes to D7.

I planed to change the _linkchecker_isvalid_response_code() function to an associative array with Name and Description as subkeys. This name could be shown instead of the status code and a mouse over may show the description... something like this was at least my idea. No code has been written for this change yet, so you can help for sure to get this done.

caesius’s picture

caesius commented

Seeing the exact response code is still useful, especially for sorting -- the "Error" column usually acts as a (somewhat terse) "Name" for the response code anyway. Moreover, you will sometimes get response codes that aren't defined as "valid" response codes; for example:

-113 No route to host
-110 Connection timed out
-1 request timed out
0 php_network_getaddresses: getaddrinfo failed: Name or service not known

I don't think writing a description for every possible response code is necessary; we should just have a more descriptive explanation of the more common ones as well as explain that 3xx/4xx/5xx errors represent distinct categories. Maybe we could have a link to either the Wikipedia or W3 page on HTTP response codes as well?

http://en.wikipedia.org/wiki/HTTP_response_codes
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.1.1

hass’s picture

hass commented

Usability wise I think it's wrong to tell users to read very long wikipedia articles. This would be bad usability. Help should be context sensitive and people should not leave the interface/website.

caesius’s picture

caesius commented

Fair enough. However, there is still the issue of how we could give more information regarding particular status codes. This key is one idea, but I've come up with another solution: First, we would add a new "Category" column to the report between the response code column and the error column that would display "Client Error", "Server Error", or "Redirection" depending on whether it's a 3xx/4xx/5xx status code. Second, certain common response codes would have a superscript question mark next to them that give a tooltip description of the error in layman's terms.

If you like this solution then I could go ahead and code it.

hass’s picture

hass commented

I wish we would get #965720: Views integration for Broken Links report finished. With this feature we may also solve the OG issue with the function names.

About the help, I think we may switch by default to a user friendly view. This means we show no longer "404" or "301". We may show "Not found" or "Moved Permanently". We need to try how we show best the RAW error message and additionally a help text for newbies. The raw message need to be shown somewhere as some suxxxx buggy webservers are giving wrong text messages and/or status codes from time to time. Additional we have status codes that are not really defined. e.g. -110 shows me firewall/loopback/php issues on the Drupal host, but it's mostly not named Connection timed out. That's why it may lead to more troubles if we try to do something intelligent for the usability that hide the read error message from the user... :-(

Can you help with #1441574: Port D6 access bypass bugfixes to D7? I'm not committing anything before this is done.

caesius’s picture

caesius commented

I don't agree with the idea of removing the status codes from the broken links report and neither does my supervisor. Though cryptic to less tech-savvy users, they are still a universal, concise, and specific method of reporting HTTP request failures, and more technical users would hate to lose a useful way of sorting through broken links. Also, if you explain that negative response codes likely indicate an issue with your webserver while 0 response codes mean the site no longer exists, than having those show up at the top is very useful. I'm not sure how getting rid of them makes the interface more user-friendly -- especially if you're still going to show the fairly technical raw error message. The user should have all available information in front of them, rather than have to think, "Is 'bad request' a client error or a server error? I don't remember; I'm going to have to look that up."

Perhaps a dedicated help page is needed specifically to (briefly) explain HTTP response codes to non-technical users -- as well as to administrative gurus wondering why they're getting ridiculous negative response codes.

As for helping with the security issue, since it will move my feature requests along more quickly I'll see what I can do. It also won't hurt to get a feel for the changes that will be coming in the next version and to possibly steer development in a direction that will make it easier for these features to be implemented.

hass’s picture

hass commented

http://drupal.org/node/965720#comment-5428694 shows my idea.

hass’s picture

hass commented
Status: Active » Closed (duplicate)

Marking as duplicate of #965720: Views integration for Broken Links report as this allow changing the page and here was no progress for long time.