Issue #912 resolved

CherryPy3 dispacher raise 404 error for quoted URI

Anonymous created an issue

I just noticed that CP3 fails to handle url encoded querystring. It was working fine with CP2. Here I'm attaching a sample app to check the behaviour...

Reported by Amit Mendapara

Comments (8)

  1. Anonymous

    I just discovered the root cause of the problem. Though, I'm not sure, can anyone tell me why `unquote` was done after `urlparse`? I think it should be done before `urlparse`. See my patch...

  2. Robert Brewer

    This behavior is by design and consistent with the URI and HTTP specs. Read a little further down the code in wsgiserver and you'll see:

    scheme, location, path, params, qs, frag = urlparse(path)


    1. Unquote the path+params (e.g. "/this%20path" -> "this path").
    3. But note that "...a URI must be separated into its components
    4. before the escaped characters within those components can be
    5. safely decoded.", sec 2.4.2 atoms = [unquote(x) for x in quoted_slash.split(path)]

    The '?' character that marks the beginning of the querystring MUST NOT be percent-encoded, as your example does. If it is so encoded, it ceases to match the http_URL production in the same way:

    http_URL = "http:" "" host [ ":" port ] [ abs_path [ "?" query ]]

    If the '?' character is encoded, it is treated in exactly the same fashion as any other path-segment character.

  3. Amit Chakradeo
           # Note that, like wsgiref and most other WSGI servers,
           # we unquote the path but not the query string.
           environ["QUERY_STRING"] = qs

    This sucks, we have fixed the client with quoting querystring only. But it's not unquoted by wsiserver. Now error 404 is gone but the querystring is not converted properly as keyword args...

  4. Anonymous

    Why don't you write a tool that will unquote them on the fly and then inject them into cherrypy.request.params?

  5. Log in to comment