Hrvoje Niksic wrote:
Frank McCown <[EMAIL PROTECTED]> writes:
But IIS does not handle ".." the same way. IIS will simply ignore
".." and produce the page. So the following two URLs are referencing
the same HTML page:
http://www.merseyfire.gov.uk/pages/fire_auth/councillors.htm
and
http://www.merseyfire.gov.uk/../pages/fire_auth/councillors.htm
The reason I bring this up is that if I use wget to access the URL
with "..", it will translate ".." into "%2E%2E" like this:
wget -r http://www.merseyfire.gov.uk/../pages/fire_auth/councillors.htm
saved to
www.merseyfire.gov.uk/%2E%2E/pages/fire_auth/councillors.htm
although it should be saved to
www.merseyfire.gov.uk/pages/fire_auth/councillors.htm
That is by design. The leading ".." in the path should be left
as-is. Saving to ".." would be wrong, and just ignoring an existing
directory also sounds wrong, which is why Wget opts to encode ".." as
"%2E%2E".
I'm not sure if I can think of a workaround for the pages that use
such a construct anyway.
I may not have made myself clear. Yes, we would not want to save to
"..". But there is no existing directory that is being ignored.
Earlier today I sent an email explaining that wget already handles ".."
in the middle of a URL correctly, it just doesn't handle ".."
immediately after the domain name correctly.
Wget will currently convert the request of
http://foo.org/BLAH/../page.html to http://foo.org/page.html. What it
should also do is convert a request for http://foo.org/../page.html to
http://foo.org/page.html. This would simply make the request save the
file to the correct location instead of foo.org/%2E%2E/page.html.
As far as I can tell, the only time you'd want to encode ".." to
"%2E%2E" would be in a query string.
Thanks,
Frank
