Previously, process_head immediately returned if there was no refresh, never giving the cache-control check further down a chance to run.
Also add new tests:
nocache.html
refresh+nocache.html
Simply search for 'url' marker ignoring anything
before it.
ELinks is now able to follow incorrectly written
meta refresh content attribute with missing ; before
url= parameter.
As an example, try http://akkada.tivi.net.pl/
Add a boolean protocol flag which says whether "//" in the path
part of an URI can be safely substituted with "/". Be conservative
and enable it only for file://, ftp:// and nntp[s]://. Other
can be turned on later, if needed.
Generalizes the fix from 58b3b1e752.
This reverts commit 4f0aaa166e
and insert check for the "//" -> "/" change only to occur for
file:// URIs. This fixes the recent reports on broken handling
of relative file URIs starting with "..".
This change:
- Adds a check for the doxygen program to configure.
- Moves the Doxyfile from src/Doxyfile to doc/Doxyfile.in.
- Generates a doc/Doxyfile from doc/Doxyfile.in inserting
an absolute path to the source directory, so that it
also works when builddir != srcdir.
- Adds `make api` rule for running doxygen; it depends on
api/doxygen file which is never created to force the rule
to always run.
All the needed memory has been allocated before the loop so we can use
copy_screen_chars() directly. This avoids the assertion failure in
copy_chars() for width==0 and should be a bit faster too. According
to ISO/IEC 9899:1999 7.21.1p2, memcpy() doesn't copy anything if n==0
(but the pointers must be valid).
(original 'git cherry-pick' arguments: cherry-pick bug968-att394)
<http://www.wikipedia.org/w/wiki.phtml?search=sue%20lawley>
incorrectly redirects to
<http://en.wikipedia.org/w/wiki.phtml?search=sue%2520lawley>
which searches for "sue%20lawley" rather than "sue lawley".
By using en.wikipedia.org directly, we avoid the server bug.
Prompted by an elinks-users post on 2007-07-27.
I asked on #wikimedia-tech, and www.wikipedia.org does always
redirect to en.wikipedia.org; it does not guess any other
language based on headers or IP addresses or such. Also, the
redirection exists only for compatibility, and skipping it
avoids a few roundtrips to the server. So this change is good
even if the server is eventually fixed.
Rename struct key to struct named_key, use more const, change the num
member from int to term_event_key_T, and put a KBD_UNDEF at the end of
the array (even though it won't be read).
Fix warnings:
dom/stack.h:70: Warning: explicit link request to 'pop_dom_node' could not be resolved
dom/stack.h:71: Warning: explicit link request to 'pop_dom_nodes' could not be resolved
dom/stack.h:71: Warning: explicit link request to 'pop_dom_state' could not be resolved
dom/stack.h:115: Warning: explicit link request to 'done_dom_node' could not be resolved
Use @returns instead of \return in src/document/css/parser.c,
and other such things.
This cleans up and changes the calling convention of
load_additional_file(), so that it now grab its own doc_view using
current_frame() and the struct session pointer in the file_to_load
object. By always looking up the current frame, corruption of doc_view
due to rerendering of the upper frame document is avoided.
The fix extends commit 6afdbf608f by
Witold, which moved the getting of doc_view in the other caller of
load_additional_file(). The additional clean up ensures that any future
users of load_additional_file() will not reintroduce a similar bug.
A possible future optimization would be to change load_additional_file()
to take the referrer as an argument.
When skipping "@media print { #foo {bar: baz} pre {white-space: normal} }",
the previous code would look for the first "{" and then the first "}", and
fail to skip the "pre" rule. Seen at support.microsoft.com.
I originally posted this change as part of attachment 383 to bug 722.
This patch changes normalize_uri() to no replace "//" with "/" in URIs. This
fixed this bug but will also lead to possibility that duplicate entries can
exist in ELinks' cache. ELinks might be able to detect in another way by
hashing the content or something.
[ From attachment 310 of bug 744. --KON ]
The previous code cast the integer (long actually) to void * and gave
that to JS_SetPrivate. This did not work because JS_SetPrivate
expects pointers to be aligned and replaces the least significant bit
with a tag. By using JS_SetReservedSlot instead, we get control of
the jsval conversions and can store the integer properly.
Revert part of commit 7215c964e40afe953787d7831b04182fbaba4662,
"Use real types (enum connection_{state,priority})." of 2005-06-14.
connection.pri[] is indexed by enum connection_priority, but its
elements are merely reference counts; they are never assigned from
or compared to enum connection_priority. Defining the elements
as int will result in more readable output from GDB.
Noted in bug 920.
Add ecmascript_interpreter.backend_nesting, increment it when
beginning to evaluate an expression, and decrement it when evaluation
finishes. Then assert that it is zero in ecmascript_put_interpreter.
This detects bug 957 and similar ones before they corrupt memory.
The history converted from CVS is not in repo.or.cz though, so keep
referring to pasky.or.cz for that. (We don't seem to use
"gitweb.elinks.cz", which is a DNS alias for pasky.or.cz.)
<paakku> Do you think we should maybe point people to gitweb at
repo.or.cz rather than pasky.or.cz?
<pasky> absolutely
<pasky> actually I thought we already are pointing people at
repo.or.cz
<pasky> at least there was some movement to do that already, I believe
:)
And reorder the characters in the string given to strcspn(), to match
their expected order in the URI. This is also how strcspn() is called
elsewhere in uri.c.
Although <see/object.h> of SEE 2.0.1131 has a comment saying that
SEE_objectclass.enumerator is optional and may be left NULL, SEE
crashes if one tries to enumerate the properties of an object created
from such a class. Conveniently, it provides a suitable stub function.
http://www.adaptive-enterprises.com.au/bugs/show_bug.cgi?id=75
I don't remember why I cleared "returns", but it doesn't work
with www.hypermedia.pl/altkom/ and probably with many more sites.
[ From commit e887efc611 on the witekfl
branch. --KON ]
This is a further precaution against reading a pointer from the wrong
type of object. All of the JS_GetPrivate calls were already protected
with JS_InstanceOf checks if assertions are enabled, and many of them
also if assertions are not enabled.
Remember the index of struct form_state in vs->form_info
instead of the pointer to it. The pointer may change,
the index is persistent.
The field ecmascript_obj of the struct form_state is unused.
screen_driver_change_hook was comparing only strlen(name) characters
and ignoring the '\0'. To reproduce the bug in ELinks 0.11.3 and
ELinks 0.12.GIT:
- Run TERM=screen elinks.
- In another terminal, run TERM=scr elinks. Quit this slave ELinks.
- Open the terminal options dialog and set 16 colors.
- Open the option manager and change the terminal.scr.colors option to
1 and back to 0.
- Note that ELinks no longer displays colors.
That bug could be fixed just by using len+1 instead of len. However,
there is also another bug: memcmp may compare the specified number of
bytes, even if some of the earlier ones differ; thus, it could in
principle read past the end of the malloc block and thereby crash
ELinks. Using strcmp may be a little slower but I do not believe it
could become a bottleneck.
Introduce get_opt() to do the tedious work of getting the right
argument for options expecting them and handles both '--opt=arg'
and '--opt arg'. As a side effect it also removes an unneeded
assignment of the source string for stdin.
Works with both bash and dash. This reintroduces the fix to the
test-sgml-parser-basic test, and also fixes test-sgml-parser-incremental
and test-sgml-parser-lines, which Witek has reported as failing.
Use it for the actual I/O only. Previously, defining CONFIG_UTF8 and
enabling UTF-8 used to force many strings to the UTF-8 charset
regardless of the terminal charset option. Now, those strings always
follow the terminal charset. This fixes bug 914 which was caused
because _() returned strings in the terminal charset and functions
then assumed they were in UTF-8. This reduction in the effects of
UTF-8 I/O may also simplify future testing.
A problem with \n replacement caused test no. 19 to fail.
Fix it by also allowing expected output to be prepared in a
file by introducing a new backend: test_output_equals_file,
also used test_output_equals.
Tested on Ubuntu Feisty Fawn with both /bin/bash and /bin/sh
where /bin/sh failed before the fix. Reported by Witek.
Don't look for gettext message catalogs in ../po/ unless ELinks is being
run as src/elinks, ./src/elinks, or .../src/elinks.
Discovered by Arnaud Giersch, this alternate fix (than what is in debian
package 0.11.1-1.4) closes debian bug #417789 and redhat bug #235411.
Also reported in: CVE-2007-2027.
Restricting it to only work with --enable-debug was also considered,
however, it is an important feature for translaters so this less
paranoid fix was chosen.
Revert commit 2d6840b9bd9d3a7a45a5ad92b4e98ff7224d6d97. It is causing
passive FTP via IPv6 to fail on ftp.funet.fi. ELinks sends PASV and
the server says "425 You cannot use PASV on IPv6 connections. Use EPSV
instead."
Because the renderer no longer does that.
The comment "We don't cope well with entities here" may now be
obsolete but I'm not sure about that so I'm leaving it in.
options->cp is still used for this in seven places where html_context
is not easily available. Those should eventually be corrected too,
but I'm checking this change in already because it's better than what
we had before.
Previously, html_special_form_control converted
form_control.default_value to the terminal charset, and init_form_state
then copied the value to form_state.value. However, when CONFIG_UTF8
is defined and UTF-8 I/O is enabled, form_state.value is supposed to
be in UTF-8, rather than in the terminal charset.
This mismatch could not be conveniently fixed in
html_special_form_control because that does not know which terminal is
being used and whether UTF-8 I/O is enabled there. Also, constructing
a conversion table from the document charset to form_state.value could
have ruined renderer_context.convert_table, because src/intl/charsets.c
does not support multiple concurrent conversion tables.
So instead, we now keep form_control.default_value in the document
charset, and convert it in the viewer each time it is needed. Because
the result of the conversion is kept in form_state.value between
incremental renderings, this shouldn't even slow things down too much.
I am not implementing the proper charset conversions for the DOM
defaultValue property yet, because the current code doesn't have
them for other string properties either, and bug 805 is already open
for that.
I am going make fc->default_value use the charset of the document, and
recoding the string from the form history to that might lose characters.
This change also affects what ECMAScript sees in the defaultValue property.
<http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-26091157>
says it should represent the HTML "value" attribute, so changing it
based on form history is not appropriate.
This does not yet fix bug 947 for the case where the document is UTF-8
and the terminal is ISO-8859-1. That will require changing charsets.c
too, it seems.
Give them a corresponding Content-Type header. This must go in
cached->head because cached->content_type is supposed to be just
type/subtype. It will also be deduced from cached->head, so don't set
it separately.
Old versions of add_string_to_string returned the target string
unmodified if from->source pointed to a null character, which usually
meant that the source string was empty. That was changed in commit
5e18576391f75ad84e04f9c8a30b93d08f0b92ab on 2004-11-03 so that
add_string_to_string instead returned NULL in that situation. The
change seems to have been inadvertent.
I'm now reverting that change and also making add_string_to_string
check the emptiness of the source string based on the stored length
only, rather than on any null characters. So the function can now
also be used with non-C strings containing embedded null characters.
Note that the previous version did not completely prevent embedded
null characters either, because it checked only the first character.
trim_chars was called only in debug mode and the results of the get_attr_val
for value=" something " in debug mode differ from normal and fastmem mode.
[ From commit c4500039b2 on the witekfl
branch. --KON ]
