187845 - URL: "//../" should be treated same as "/../"

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[David Ljung Madison]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021217 Phoenix/0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021217 Phoenix/0.5

"//" should be treated like "/" - so if we see "//../" in a URL, this should
be treated the same as "/../" - but mozilla is stripping the ".." out and we
look at the wrong directory.

For example:

http://www.google.com/images//../logo.gif

Should be the same as:

http://www.google.com/images/../logo.gif

But is instead treated as:

http://www.google.com/images/logo.gif

(and yes, this is an actual image, but it shouldn't be accessed by the given url).

file: is also effected.


Reproducible: Always

Steps to Reproduce:
1. Load: http://www.google.com/images//../logo.gif
Actual Results:  
Went to the wrong location [http://www.google.com/images/logo.gif]

Expected Results:  
Gone to:  http://www.google.com/images/../logo.gif

(And see the appropriate 401 from google)

Comment 1

[Nicholas Allen]

*** Bug 187844 has been marked as a duplicate of this bug. ***

Comment 2

[Dan Mellem]

I've been searching for this but the only information I can find on a double
slash is to designate a network device when it's at the beginning of the URI.
(RFC 1808 & 2396) Also, I believe that an absolute path should be passed to the
server exactly.

Changing OS=all

Comment 3

[Ruslan Ismailov]

Accordin to RFC 2396 (http://www.ietf.org/rfc/rfc2396.txt) // could not be
occured in URI, other than scheme delimeter. It definitly newer could be treated
as /. If // appeared not as a scheme delimeter, following rules should apply:

    path_segments = segment *( "/" segment )
    segment       = *pchar *( ";" param )

So // could be treated as /[empty char]/ or have specific meanings (such as
"index"). It could not be parse as /.

Comment 4

[David Ljung Madison]

I don't see why considering // to be /[empty char]/ would preclude it from
acting like /./, as does UNIX and most OS, as well as most browsers and web
servers that I've known.

Comment 5

[Ruslan Ismailov]

Because RFC stricly described process of URI parcing. 
First, take in mind, that

 URI that are hierarchical in nature use the slash "/" character for
   separating hierarchical components.  For some file systems, a "/"
   character (used to denote the hierarchical structure of a URI) is the
   delimiter used to construct a file name hierarchy, and thus the URI
   path will look similar to a file pathname.  This does NOT imply that
   the resource is a file or that the URI maps to an actual filesystem
   pathname.

and 

   Within a relative-path reference, the complete path segments "." and
   ".." have special meanings: "the current hierarchy level" and "the
   level above this hierarchy level", respectively.  Although this is
   very similar to their use within Unix-based filesystems to indicate
   directory levels, these path components are only considered special
   when resolving a relative-path reference to its absolute form
   (Section 5.2).

Second, // inside path is invalid:    
The path may consist of a sequence of path segments separated by a
   single slash "/" character.  Within a path segment, the characters
   "/", ";", "=", and "?" are reserved.  Each path segment may include a
   sequence of parameters, indicated by the semicolon ";" character.
   The parameters are not significant to the parsing of relative
   references.

There stated
      e) All occurrences of "<segment>/../", where <segment> is a
         complete path segment not equal to "..", are removed from the
         buffer string.  Removal of these path segments is performed
         iteratively, removing the leftmost matching pattern on each
         iteration, until no matching pattern remains.

So "first/second/..//" should be parsed as "first/", not as "first".

Comment 6

[David Ljung Madison]

> Second, // inside path is invalid:  

I disagree:

> the characters "/", ";", "=", and "?" are reserved...

Right - so this implies that the path segment between the '/' is ''
which is valid according to the RFC:

    segment       = *pchar *( ";" param ) 

The question is, what to do with a null segment in general, and
what to do with a null segment followed by "/../" (arguably this
should be consistent).

> e) All occurrences of "<segment>/../", where <segment> is a 
>    complete path segment not equal to "..", are removed from the

So the question I have here is, what is a "complete" path segment?
(Does a "null segment" qualify?)

Perhaps there should be an additional rule before rule e) that states
that any '//' should be converted to '/' - though I know this isn't currently
in the RFC.

Comment 7

[Andreas Otte]

I will take a look, if this can easily be done. The empty segment argument makes
sense to me. However Windows does not take // kindly when it ends up as part of
an absolute path (and is not an UNC path). 

Comment 8

[Andreas Otte]

Upon further looking into this I think the current behavior (interpreting // as
empty segment and not as /) is the correct one in conformance with rfc 2396.
Interpreting // as / is a unix filesystem only feature which has no real meaning
for hierachical url paths. The same thing goes for ... which has special meaning
on Win98 but nowhere else. Recommend INVALID.

Comment 9

[Kenneth Herron]

Resolving invalid per the discussion.