Last modified: 2010-05-15 15:32:55 UTC
Use search to search for a page like "A.." (without the quotes). When it's not found, you are given the ability to create the page. But if you create the page, upon save you are taken to the "A" page. It's almost impossible to actually display the page (I did it by using the curid). I'm not sure if the bug lies in being able to create a faulty page name, or if there's a problem in parsing the address information.
I created a page called "A.." and was able to view and delete it at the expected title, [[A..]].
I typoed in the original description. There was only supposed to be a single period, not two. However, on Wikipedia, it works fine even with only one period. However, it works as I described on my test system. I'm running under WinXP, with no caching. I would appreciate if someone could reproduce the text on a similar system, so I know if there's something specific to my setup, or something with WinXP, or something with the non-cached situation.
Still works fine on Wikipedia. [[A.]]
Are you running on Apache, IIS, or some other server? Have you tested only in Internet Explorer, or also other browsers? What's the URL style you're using (eg, "/index.php/Foo" or "/index.php?title=Foo" or a manually configured rewrite setup)? If using one of those forms, does accessing via the other work?
As usual, Brion, you're questions are on target. There's no problem using "/index.php?title=Foo", but it fails using "/index.php/Foo". I've verified this behavior using both IE 6.0 SP2 and Firefox 1.0. I'm running Apache 2.0.52 on Windows XP Home SP2.
I can't reproduce on Apache 1.3 on Mac OS X, so it may be specific either to Apache 2.0 or to Apache on Windows. (Windows doesn't allow a filename to end with a period, so filename validation code might be overzealously trimming it.) Will do more testing when I've got my PC back home and running. Reopening, changing summary.
This is in the ASF bug database for "Apache httpd-2.0" under Windows. See http://issues.apache.org/bugzilla/show_bug.cgi?id=20036 ("Trailing Dots stripped from PATH_INFO environment variable"). For other Apache 2.0 issues with PATH_INFO, see http://issues.apache.org/bugzilla/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__all__&product=Apache+httpd-2.0&content=PATH_INFO One work-around is to stop using pretty URLs by setting $wgUsePathInfo to false in LocalSettings.php. Patch to follow.
Created attachment 647 [details] HEAD patch for WebRequest.php This patch for 1.5cvs restores trailing periods stripped from PATH_INFO by Apache 2.0 under Windows. Tested with Windows 2000 & Apache 2.0.50.
Is it possible to fix bug 2088 in the same style?
(In reply to comment #9) > Is it possible to fix bug 2088 in the same style? See bug 2088 comment 5.
I've seen lots of problems with REQUEST_URI and SCRIPT_NAME interacting weirdly with CGI and/or rewrite rule-type subdomain rewriting. Has this been tested under these conditions?
(In reply to comment #11) Not by me. But the new function tries to be defensive of supplied values to avoid erronous results from unexpected/missing PATH_INFO/SCRIPT_NAME/REQUEST_URI combinations. If other configurations/versions/platforms have the same issue and are not fixed by the patch, please report the details here.
*** Bug 4316 has been marked as a duplicate of this bug. ***
My article "Harry Aubrey Toulmin, Sr." ends in a period ("."). On bringing up my article [Harry Aubrey Toulmin, Sr.], the URL link listed is "http://en.wikipedia.org/wiki/Harry_Aubrey_Toulmin%2C_Sr". I booked mark that link and it has always worked for me. I sent this URL to important people connected with Mr. Toulmin (relatives, historians) but not connected with Wikipedia to review and contribute to the article and for some reason, they cannot pull up the article from the link http://en.wikipedia.org/wiki/Harry_Aubrey_Toulmin%2C_Sr . These experts in the field appear to be discourage from contributing to the article because they cannot pull the article up. A post on Wikipedia:Village pump (technical) suggested I use the link "http://en.wikipedia.org/wiki/Harry_Aubrey_Toulmin%2C_Sr% 2E". I do not want to send these people another link until I know for sure it will work. I prefer to have a straight forward link such as http://en.wikipedia.org/wiki/Harry_Aubrey_Toulmin_Sr without all the %2C and %2E in it. Can you make this happen? Also, as one poster at Bug 4316 suggested, you really should prevent people from ending the name of their article with a period to avoid trouble such as the above or fix this bug.
(In reply to comment #14) A simple work-around is to create redirect pages, which I have done for you. You can now direct people to http://en.wikipedia.org/wiki/Harry_Aubrey_Toulmin_Sr (which you indicated you prefer), and they will get to the page you want them to get to.
Actually, this is a deeper problem: trailing periods aren't allowed in URIs. See http://www.ietf.org/rfc/rfc3986, section 5.2.4. Many browsers seem to handle them just fine but some don't. The same is true for packages that parse URIs and follow a strict interpretation of the standard. Just to clarify: the problem isn't periods within page titles, it's one or two periods at the end of an URL.
(In reply to comment #16) > Actually, this is a deeper problem: trailing periods aren't allowed in URIs. See > http://www.ietf.org/rfc/rfc3986, section 5.2.4. As discussed on IRC, I think this reading of the standard is clearly incorrect. Only a trailing "/.." is treated specially, not simply a trailing "..".
This should have been resolved by the new title interpolation code in 1.10 or 1.11. Resolving as FIXED; reopen if still encountering such troubles.
