".." in it except in the query string. Therefore ".." would never
need to be encoded since a query string with "blah/../blah" would always
be encoded to "blah%2F..%2Fblah" and would not affect the file system path.
Frank
I wanted to let you know
a URL
request with ".." in it except in the query string. Therefore ".."
would never need to be encoded since a query string with
"blah/../blah" would always be encoded to "blah%2F..%2Fblah" and would
not affect the file system path.
Frank
Here
But according to the new rfc3986 sec 5.4.2, the ".."
should be removed from the beginning of the URL path.
With this new behavior implemented, wget would never make a URL request
with ".." in it except in the query string. Therefore ".." would never
need to be e
ct-file-names", required_argument, NULL, 176 },
{ "save-cookies", required_argument, NULL, 162 },
{ "timeout", required_argument, NULL, 'T' },
{ "tries", required_argument, NULL, 't' },
@@ -609,6 +611,9 @@
break;
cas
/* Two more characters (hex digits) */
+
+ if (!addition)
+return (char *)s;
+
+ newlen = (p1 - s) + addition;
+ newstr = (char *)xmalloc (newlen + 1);
+
+ p1 = s;
+ p2 = newstr;
+ while (*p1)
+ {
+ if (UNSAFE_CHAR (*p1))
+ {
+ const unsigned char c = *p1++;
+ *
t that works on other browsers, and not
on some.
The solution is to have url_filename and friends call different,
file-name related functions. They should:
a) Be able to encode truly illegal or strange characters in URL. For
example, slashes may well appear in query string:
baz?x=h
ifferent ways depending on whether
directories are being created or not. There is also a specific
problem with the code putting an explicit '?' in the file-name for
a query string, which is illegal for a Windows filen-name. These
issues need to be dealt with.
As for your examples, an U
