Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Request to url_prefix yields wrong PATH_INFO #46

Closed
t-8ch opened this Issue · 3 comments

2 participants

@t-8ch

If the origin request path is exactly the same as the url_prefix the
resulting PATH_INFO equals the SCRIPT_NAME whereas it should be the empty string.

Example:

$ URL_PREFIX=/foo # imagine, waitress using this
$ curl localhost/foo
SCRIPT_NAME=/foo
PATH_INFO=/foo

PEP-333, the WSGI-specification says this:

PATH_INFO
    The remainder of the request URL's "path", designating the virtual "location" of the request's target within the application. This may be an empty string, if the request URL targets the application root and does not have a trailing slash.

Testcase:

def test_get_environ_with_url_prefix_empty_path(self):
    inst = self._makeOne()
    inst.channel.server.adj.url_prefix = '/foo'
    request = DummyParser()
    request.path = '/foo'
    inst.request = request
    environ = inst.get_environment()
    self.assertEqual(environ['PATH_INFO'], '')
    self.assertEqual(environ['SCRIPT_NAME'], '/foo')

I think the testcase collides with test_get_environment_path_empty.
But I think this test case is invalid, as a request with an empty path would
not be valid HTTP.

@mcdonc mcdonc referenced this issue from a commit
@mcdonc mcdonc - When the ``url_prefix`` adjustment starts with more than one slash,…
… all

  slashes except one will be stripped from its beginning.  This differs from
  older behavior where more than one leading slash would be preserved in
  ``url_prefix``.

- If a client somehow manages to send an empty path, we no longer convert the
  empty path to a single slash in ``PATH_INFO``.  Instead, the path remains
  empty.  According to RFC 2616 section "5.1.2 Request-URI", the scenario of a
  client sending an empty path is actually not possible because the request URI
  portion cannot be empty.

- If the ``url_prefix`` adjustment matches the request path exactly, we now
  compute ``SCRIPT_NAME`` and ``PATH_INFO`` properly.  Previously, if the
  ``url_prefix`` was ``/foo`` and the path received from a client was ``/foo``,
  we would set *both* ``SCRIPT_NAME`` and ``PATH_INFO`` to ``/foo``.  This was
  incorrect.  Now in such a case we set ``PATH_INFO`` to the empty string and
  we set ``SCRIPT_NAME`` to ``/foo``.  Note that the change we made has no
  effect on paths that do not match the ``url_prefix`` exactly (such as
  ``/foo/bar``); these continue to operate as they did.  See
  #46

Fixes #46
735adb0
@mcdonc mcdonc closed this issue from a commit
@mcdonc mcdonc - When the ``url_prefix`` adjustment starts with more than one slash,…
… all

  slashes except one will be stripped from its beginning.  This differs from
  older behavior where more than one leading slash would be preserved in
  ``url_prefix``.

- If a client somehow manages to send an empty path, we no longer convert the
  empty path to a single slash in ``PATH_INFO``.  Instead, the path remains
  empty.  According to RFC 2616 section "5.1.2 Request-URI", the scenario of a
  client sending an empty path is actually not possible because the request URI
  portion cannot be empty.

- If the ``url_prefix`` adjustment matches the request path exactly, we now
  compute ``SCRIPT_NAME`` and ``PATH_INFO`` properly.  Previously, if the
  ``url_prefix`` was ``/foo`` and the path received from a client was ``/foo``,
  we would set *both* ``SCRIPT_NAME`` and ``PATH_INFO`` to ``/foo``.  This was
  incorrect.  Now in such a case we set ``PATH_INFO`` to the empty string and
  we set ``SCRIPT_NAME`` to ``/foo``.  Note that the change we made has no
  effect on paths that do not match the ``url_prefix`` exactly (such as
  ``/foo/bar``); these continue to operate as they did.  See
  #46

Fixes #46
735adb0
@mcdonc mcdonc closed this in 735adb0
@mcdonc
Owner

Thank you! I've fixed this in master.

@mcdonc
Owner

Waitress 0.8.8 is out with this fix.

@t-8ch

Many thanks for the fast fix and also waitress in general!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.