isup: fix error-series HTTP status codes; get away from assuming TLD #1940
Conversation
This explains so much about how I'd check a site that's clearly down if I visit it in my browser and Sopel would say it's fine.
dgw
added
Tweak
Bugfix
The "com" TLD is nowhere near as common as it once was. It's probably better to just inform the user that they forgot a dot, or tried to look up a local (unqualified) name that Sopel won't be able to access. Sopel definitely shouldn't just skip enforcing the presence of a dot, since LAN names' existence shouldn't be accessible this way. Left a TODO comment about mitigating this kind of risk.
I understand what you say with that quoted "down", and I'd say we need to inform the end-user about the difference between being unreachable, falling into a server error (5xx), and just a URL that cannot be accessed from here (4xx). For instance, 401/403 means the site requires authentication/authorization, not that it is down. The same way, a 404 may mean that you are trying an URL that doesn't return anything, and yet, the site itself isn't down, you can still access it. So, maybe we should change the message for these cases instead. |
|
Hmm… That makes a lot of sense, though I was (unconsciously?) associating our |
Yes! |
|
Took care of my last TODO. Ready for a real look. 😸 |
Includes tests, since that's how I verified that it used to be allowed.
Description
Unbelievably,
isuphas been sometimes (often?) returning "looks fine" for sites that send back error status codes, e.g. HTTP 4xx, 5xx. Those should be considered "down".I also threw in a couple other little tweaks, the important one being that a bare name like
googlewill no longer assumegoogle.comas the input. (There's one last TODO left for myself before this PR is actually ready for review, about properly handling full URLs that contain a.but refer to a LAN name.)Checklist
make qa(runsmake qualityandmake test)