404 Handling [BUG REPORT]

[Boruch Baum <boruch_baum@xxxxxxx>]

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))





-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0