HTTP errors not handled well with Lynx #190
Labels
No Label
blocked
bug
build
documentation
duplicate
enhancement
finger
gemini
gopher
help wanted
http
in progress
invalid
local
needs-info
non-code
non-functional
non-urgent
question
release
rendering
suggestion
telnet
terminal
urgent
wontfix
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: sloum/bombadillo#190
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Version: Bombadillo 2.2.0-28-ge06de9b (as well as latest develop branch)
Behaviour: When browsing a web site and an error like 404 would occur, the actual error page is not displayed. No page loads, and the following error is displayed at the bottom of the screen:
lynx error: exit status 1
. w3m and links do not have this issue, and load the relevant error page.Expected behaviour: The error page should be loaded.
Steps to reproduce:
Cause:
When lynx dumps a HTTP error page, the page is dumped normally to stdout but the return code is 1.
I can't see a way to get Lynx to exit on code 0 when dumping a 404 page. We could have a lynx specific check to continue processing the dumped page even if the exit code is 1. Or, can we detect and display any error responses when we do
http.IsTextFile
and display them as error messages like how Gemini does?This is an odd one. It doesn't seem to me that lynx should be throwing that for a 404... it is not a program error and shouldnt trigger a non-zero exit code. I suppose we'll have to work around it though.
We may be able to do something like (pseudocode):
I'd want to play around with intentionally getting different kinds of errors. Alternately I agree we could just convert any error message to text and display it as if it were the page...
I believe I have a solid fix for this. I am crashing out for the night but will open a PR tomorrow.
This is addressed by #196, which has been merged into a release branch. I'll close this out wants the release is done.