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.
Conflicts:
NEWS (bug 939 was listed twice)
doc/man/man5/elinks.conf.5 (regenerated)
po/fr.po (only in comments and such)
po/pl.po (only in comments and such)
src/protocol/fsp/fsp.c (the relevant changes were already here)
*fresult pointed to nowhere. On FreeBSD *fresult == NULL
and directories weren't displayed.
Check also if safe_write writes all data.
(cherry picked from commit 06bcc48487)
cached->id => cached->cache_id
document->id => document->cache_id
onload_snippets_owner => onload_snippets_document_id
Added the distinct document->document_id.
Always reset ecmascript when a document changes for example a next chunk
of it is loaded.
This bug was revelead while using bittorrent.
For filenames started with a dot and two slashes .//
the open_bittorrent_file returned -1 and set errno to EEXIST.
elinks --config-help used to sort options like this:
document.history
document.history.global
document.history.global.enable
document.history.global.max_items
document.history.global.display_type
document.history.keep_unhistory
Now it'll instead be:
document.history
document.history.keep_unhistory
document.history.global
document.history.global.enable
document.history.global.max_items
document.history.global.display_type
i.e. all the options listed under a subheading are children of the
tree named by it. This makes elinks.conf(5) look saner.
If the user opens the same file again after it is in the cache, then
ELinks does not always open a new connection, so download->conn can be
NULL in init_type_query(), and download->conn->cgi would crash.
Don't read that, then; instead add a new flag cache_entry.cgi, which
http_got_header() sets or clears as soon as possible after the cache
entry has been created.
CGI scripts are distinguishable from normal files. I hope that this
fixes the bug 991. This commit also reverts the previous revert.
(cherry picked from commit 7ceba1e461)
libsmbclient's stdout and stderr interferred with ELinks's stdout
and stdin. That caused an assertion failure. Now the ELinks uses
different streams for processing of the smb protocol.
This reverts commit 7ceba1e461,
which is causing an assertion to fail if I open the same PDF
twice in a row, even if I cancel the dialog box when ELinks
first asks which program to run:
INTERNAL ERROR at /home/Kalle/src/elinks-0.12/src/session/download.c:980: assertion download && download->conn failed!
Forcing core dump! Man the Lifeboats! Women and children first!
But please DO NOT report this as a segfault!!! It is an internal error, not a
normal segfault, there is a huge difference in these for us the developers.
Also, noting the EXACT error you got above is crucial for hunting the problem
down. Thanks, and please get in touch with us.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1216698688 (LWP 17877)]
0xb7a02d76 in raise () from /lib/libc.so.6
(gdb) backtrace 6
at /home/Kalle/src/elinks-0.12/src/util/error.c:179
fmt=0x816984c "assertion download && download->conn failed!")
at /home/Kalle/src/elinks-0.12/src/util/error.c:122
cached=0x8253ca8) at /home/Kalle/src/elinks-0.12/src/session/download.c:980
cached=0x8253ca8, frame=0)
at /home/Kalle/src/elinks-0.12/src/session/download.c:1339
at /home/Kalle/src/elinks-0.12/src/session/task.c:493
(More stack frames follow...)
There is a fix available but I don't trust it yet.
This reverts commit d0be89a16c, and thus
restores the ELinks 0.11 behaviour: always copy the data to a
temporary file before passing it to a MIME handler, even if the
"file:" URI scheme is being used. Previously, ELinks 0.12.GIT passed
the name of the original file directly to the handler. That was more
efficient but unfortunately gave the wrong result with local CGI.
The commit being reverted also claims to partially fix bug 238
(caching of local files). That bug is still open.
Currently, when ELinks passes the name of a local file to an external
MIME handler program, it encodes the name as a URI. Programs
typically do not expect this, and they then fail to open the file.
This patch makes ELinks instead quote the file name for the shell.
(The patch was attachment 425 of bug 991, by Witold Filipczyk.
This commit message was written by Kalle Olavi Niemitalo.)
Currently, when ELinks passes the name of a local file to an external
MIME handler program, it encodes the name as a URI. Programs
typically do not expect this, and they then fail to open the file.
ELinks should instead quote the file name for the shell.
Unfortunately, Debian has lines like this in /etc/mailcap:
audio/mpeg; xmms '%s'; test=test "$DISPLAY" != ""
If ELinks were changed to replace the %s with e.g.
'/home/Kalle/doc/Topfield/How to upgraded the Firmware(English).pdf'
(quotes included), then the quotes would cancel out and the shell
would split the file name into multiple arguments. That could even
provide a way for malicious persons to make ELinks run arbitrary
shell commands.
The examples in RFC 1524 all have %s without any quotes.
Debian has two bug reports about the quoting behaviour:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=90483http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221717
This patch therefore tries to detect whether the %s has been quoted
already, and remove the quotes if so. That way, the next patch will
be able to safely add its own quotes. This removal of quotes applies
only to mailcap files; MIME handlers defined in elinks.conf should
already be in the format preferred by ELinks.
(The patch was attachment 438 of bug 991, by Witold Filipczyk.
This commit message was written by Kalle Olavi Niemitalo.)
This syncs some changes (ie. -> e.g. etc.) from elinks-0.12 or beyond.
I noticed them while updating the web pages, and apologize that I will
not spent the time to attribute it to the individual commits.
(cherry picked from commit 2bfc7b3724,
omitting generated files)
Previously, file extensions added or modified via the menu did not get
saved to elinks.conf when config.saving_style was 3 (the default).
This patch makes the file-extension dialog box call option_changed,
which then sets OPT_TOUCHED, so that the option appears modified in
the option manager and will be saved.
Reported and patch reviewed by Witold Filipczyk.
