Last modified: 2010-05-15 15:32:55 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1519 - Final period ignored using PATH_INFO URLs on Apache2/Win32
Final period ignored using PATH_INFO URLs on Apache2/Win32
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
PC All
: Low minor with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
: 4316 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2005-02-13 05:01 UTC by Richard J. Holton
Modified: 2010-05-15 15:32 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

HEAD patch for WebRequest.php (1.95 KB, patch)
2005-06-25 14:20 UTC, Zigger

Description Richard J. Holton 2005-02-13 05:01:10 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.
Comment 1 Jeff Bonham 2005-02-13 05:04:21 UTC
I created a page called "A.." and was able to view and delete it at the expected title, [[A..]]. 
Comment 2 Richard J. Holton 2005-02-13 05:21:23 UTC
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.
Comment 3 Jeff Bonham 2005-02-13 05:26:11 UTC
Still works fine on Wikipedia. [[A.]] 
Comment 4 Brion Vibber 2005-02-13 07:56:50 UTC
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?
Comment 5 Richard J. Holton 2005-02-13 14:16:13 UTC
As usual, Brion, you're questions are on target.

There's no problem using "/index.php?title=Foo", but it fails using

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.

Comment 6 Brion Vibber 2005-02-13 18:44:02 UTC
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.
Comment 7 Zigger 2005-06-25 14:17:02 UTC
This is in the ASF bug database for "Apache httpd-2.0" under Windows.  See ("Trailing Dots stripped
from PATH_INFO environment variable").

For other Apache 2.0 issues with PATH_INFO, see

One work-around is to stop using pretty URLs by setting $wgUsePathInfo to false
in LocalSettings.php.

Patch to follow.
Comment 8 Zigger 2005-06-25 14:20:04 UTC
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.
Comment 9 Niklas Laxström 2005-06-25 14:30:44 UTC
Is it possible to fix bug 2088 in the same style?
Comment 10 Zigger 2005-06-25 14:55:52 UTC
(In reply to comment #9)
> Is it possible to fix bug 2088 in the same style?
See bug 2088 comment 5.
Comment 11 Brion Vibber 2005-10-08 01:06:52 UTC
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 
Comment 12 Zigger 2005-10-29 03:36:23 UTC
(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 
If other configurations/versions/platforms have the same issue and are not fixed 
by the patch, please report the details here.
Comment 13 Brion Vibber 2005-12-19 20:29:22 UTC
*** Bug 4316 has been marked as a duplicate of this bug. ***
Comment 14 James Referee 2006-10-19 13:23:45 UTC
My article "Harry Aubrey Toulmin, Sr." ends in a period (".").  On bringing up my 
article [Harry Aubrey Toulmin, Sr.], the URL link listed 
is "".  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 .  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 "
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 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.
Comment 15 Richard J. Holton 2006-10-19 14:09:55 UTC
(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 
(which you indicated you prefer), and they will get to the page you want them to 
get to.
Comment 16 Sebastian Moleski 2006-12-22 11:39:59 UTC
Actually, this is a deeper problem: trailing periods aren't allowed in URIs. See, 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.
Comment 17 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-22 15:50:21 UTC
(In reply to comment #16)
> Actually, this is a deeper problem: trailing periods aren't allowed in URIs. See
>, 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 "..".
Comment 18 Brion Vibber 2008-02-12 22:37:07 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.