Page MenuHomePhabricator

Final period ignored using PATH_INFO URLs on Apache2/Win32
Closed, ResolvedPublic

Description

Author: richholton

Description:
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.


Version: 1.4.x
Severity: minor
Platform: PC

Details

Reference
bz1519
TitleReferenceAuthorSource BranchDest Branch
Remove custom "Add more repository details to harbormaster build steps"repos/phabricator/phabricator!23aklapperT351958wmf/stable
Remove broken custom code in DifferentialRevisionSearchEngine.phprepos/phabricator/phabricator!22aklapperT351957wmf/stable
Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 8:13 PM
bzimport set Reference to bz1519.
bzimport added a subscriber: Unknown Object (MLST).

silsor wrote:

I created a page called "A.." and was able to view and delete it at the expected title, [[A..]].

richholton wrote:

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.

silsor wrote:

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?

richholton wrote:

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.

zigger wrote:

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.

zigger wrote:

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.

Attached:

Is it possible to fix bug 2088 in the same style?

zigger wrote:

(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?

zigger wrote:

(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. ***

jimreferee wrote:

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.

richholton wrote:

(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.

sebmol wrote:

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.

ayg wrote:

(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.