Request to url_prefix yields wrong PATH_INFO #46

Closed
t-8ch opened this Issue Nov 14, 2013 · 3 comments

Projects

None yet

2 participants

@t-8ch
t-8ch commented Nov 14, 2013

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 added a commit that referenced this issue Nov 21, 2013
@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 added a commit that closed this issue Nov 21, 2013
@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 Nov 21, 2013
@mcdonc
Member
mcdonc commented Nov 21, 2013

Thank you! I've fixed this in master.

@mcdonc
Member
mcdonc commented Nov 30, 2013

Waitress 0.8.8 is out with this fix.

@t-8ch
t-8ch commented Nov 30, 2013

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