Weak points:
- alignof
- js problems
Todo:
- make js work with C++ and mozjs-17
- then mozjs-24
- then mozjs-52
- then mozjs-60
- decrease number of warnings
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 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 ]
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.
Before it was only to get the password when the user name was also
requested. This fixes FSP access to password protected directories.
The problem was discovered by Witold and mentioned in the post to
elinks-dev with the message-id: <20061209204151.GA32758@pldmachine> on
2006-12-09.
A simple "update" of Hugo Haas' patch posted for bug 107. This of course
also affects the (undocumented?) feature of file:// refering to the local
directory in that directories named "localhost" can no longer be displayed
using file://localhost. Nobody should do that anyway.
In protocol/common.c length of string is known, so pass it
instead of -1 to encode_uri_string.
Introduced encode_win32_uri_string, because there were problems
with : and \ in base href.
This is utterly silly and breaks plenty of stuff - Witek, you CAN'T append
slashes to all hosts just because some silly referer needs it, everywhere
else we NEED the hosts without slashes!
The file URI encoding is done in translate_url() immediately after the call
to find_uri_protocol() [which also uses check_whether_file_exists()]. So it
only makes sense to use check_whether_file_exists() also here since this is
a potential ambiguous URL from the user.
This fixes handling of files like 'a?b' given the command line, reported by
rrowan. It broke (for the n-th time ;) in CVS version 1.317->1.318 back in
August. The fix preserves the intend of that patch, namely the intend to
optimize the number of calls to file_exists().
