Move connection.post_fd to http_post.post_fd.
Make connection.done point to the new done_http_connection(),
which calls the new done_http_post(), which closes post_fd.
So done_connection() no longer needs to do that.
Now that done_http_post() exists, a later commit can add dynamically
allocated data in struct http_post and ensure that it will be freed.
As the comment near the end of this function says, conn->info is
already non-NULL if a HTTPS proxy is being used, and the code in fact
correctly frees the previous info. So there is no need to assert its
nonexistence. I added that bug on 2008-05-22, in commit 291a913d1e.
If ELinks is being linked with SSL library, use its random number
generator.
Otherwise, try /dev/urandom and /dev/prandom. If they do not work,
fall back to rand(), calling srand() only once. This fallback is
mostly interesting for the Hurd and Microsoft Windows.
BitTorrent piece selection and dom/test/html-mangle.c still use rand()
(but not srand()) directly. Those would not benefit from being
unpredictable, I think.
To reduce code duplication, src/protocol/file/cgi.c no longer parses
connection->uri->post on its own but rather calls the new function
http_read_post_data(), provided by src/protocol/http/http.c. The same
code is now also used for POST requests that do not include files.
Previously, init_type_query would check to make sure that it doesn't create a
duplicate type query and would return NULL if it otherwise would create a
duplicate. Then setup_download_handler would return 0 to do_move.
This patch changes setup_download_handler to return 1 to do_move in this
situation so that do_move stops trying to load the document.
This avoid a crash when loading twice the same file in the same tab when
loading the file opens a type query.
The older help2doc script is no longer used for anything.
To make future cherry-picking easier, this commit does not include the
resulting changes in generated files.
The intention is to convert --config-help and --long-help outputs to
DocBook XML and XHTML rather than AsciiDoc, so that the converter does
not have to work around the intricate AsciiDoc syntax. However, this
commit does not yet connect the script to doc/Makefile.
XHTML could be generated from DocBook XML, but the script outputs it
directly because our DocBook is primarily intended for manual pages
and so does not have all the links that are useful in HTML.