[mod_python] dot dot in the url

Someone who is more knowledgeable on this may want to comment, but the
RFC for what a URI is and how it should be interpreted gives special
meaning to '../' and './', and it specifically says how they are meant
to be deal with by a server before being interpreted. You appear to be
wanting to side step the RFC and ignore what the standard says and
have it interpreted your way which just seems wrong.

For example, the RFC says:

   The path segments "." and "..", also known as dot-segments, are
   defined for relative reference within the path name hierarchy.  They
   are intended for use at the beginning of a relative-path reference
   (Section 4.2) to indicate relative position within the hierarchical
   tree of names.  This is similar to their role within some operating
   systems' file directory structures to indicate the current directory
   and parent directory, respectively.  However, unlike in a file
   system, these dot-segments are only interpreted within the URI path
   hierarchy and are removed as part of the resolution process (Section
   5.2).

Note how it says that are removed as part of the resolution process.
It is the web server here that is doing the resolution process. Only
after that resolution process can it validly map it to a particular
handler. You only get the resolved path and that is how it is meant to
be.

For more details see:

  http://www.ietf.org/rfc/rfc2396.txt
  http://www.ietf.org/rfc/rfc3986.txt

You just seem to be going about this the wrong way. Why do you expect
a URI that resolves to be outside of the base URI for your handler to
still result in your handler being called? If it is important that it
isn't, you should be generating URIs that map to outside of your base
URI in the first place.

Graham

On 12/05/07, Roger Binns <rogerb at rogerbinns.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Graham Dumpleton wrote:
> > If your web browser doesn't normalise it
>
> I am sending requests from my test harness which does not do
> normalization.  In my case normalization effectively "corrupts" the data.
>
> > then Apache will. Such
> > normalisation will be done before it even gets to mod_python.
>
> req.uri is normalized but req.unparsed_uri is as originally sent by the
> client, so I use that.  The only remaining problem is that if the
> normalized uri doesn't reference my handler then it isn't called.
>
> <Location /api/v1/>
>  SetHandler python-program
>  PythonHandler restapiv1::RestAPIV1.RequestHandler
> </Location>
>
> So I get called for /api/v1/widget/a/b/c/d/../../e but not for
> /api/v1/widget/../../e/a/b/c/d
>
> > You state want you want to happen, but why exactly do you want to do
> > this in the first place? What is the underlying reason?
>
> Exactly as I said.  It is a rest service and the names of items appear
> as part of the URL.  eg You use PUT /api/v1/widget/foo to create a
> widget named foo, GET to query it, DELETE to delete it etc.
>
> But because of this normalization done by Apache before deciding which
> handler to call, that imposes an arbitrary constraint on names such that
> they can't have ../ sequences that get up before the /api/v1/.  The
> arbitrary constraint then has to be documented, tested, have friendly
> information in user interfaces etc.  It is an ugly wart and I was hoping
> it was unnecessary.
>
> Roger
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGRVS3mOOfHg372QQRAulYAJ90JYiXJ+FSkQzJPNpdlTCFJFSYvgCfbzw4
> 1FKXPA+JqBzWAufEfSe13CA=
> =ZdiB
> -----END PGP SIGNATURE-----
> _______________________________________________
> Mod_python mailing list
> Mod_python at modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
>