[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
404 Handling [BUG REPORT]
- From: Boruch Baum <boruch_baum@xxxxxxx>
- Date: Thu, 12 Apr 2018 16:33:41 -0400
- X-ml-name: emacs-w3m
- X-mail-count: 12955
Today, as part of some editing on the emacs wiki, I created a new page
to document how to translate emacs-w3m web pages. The method that the
wiki uses for web page creation is to first create a CamelCase word in
an existing wiki page, which will be the link to the new page, and then
click on that link, which returns a _response page_ saying that the url
does not exist, but you can create it by pressing "this link".
However, that _response page_ is a 404 response, and emacs-w3m does
something non-standard for many responses: instead of continuing to
parse the page, emacs-w3m displays its header information.
This emacs wiki example illustrates why that method of handling
responses is deficient - if the response includes HTML, it should be
parsed and presented. Many websites have custom 404 messages, sometimes
with useful information and links.
Currently, there does exist a boolean variable
`w3m-show-error-information' which controls whether
to display the header information for the response, and it defaults to
`t'. It should, IMO, default to nil.
A problem though, is that setting the value nil didn't help! The page
still wasn't rendered. In trying to debug the issue, I did find and
solve a secondary bug being: Function `w3m-create-page', calls
`completing-read' with a mal-formed COLLECTION argument. It reads
(cons "Download_or_External-view" w3m-content-type-alist)
when I think it should be:
(cdr (cons "Download_or_External-view" w3m-content-type-alist))
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0