In reviewing my code in this area, I also see that in addition to fixing _url_collapse_path_split, I override the location that uses it, which is the is_cgi function.  Here is my code for the override, which actually creates a proper PATH_INFO string:

        def is_cgi(self):
            """Test whether self.path corresponds to a CGI script.

            Returns True and updates the cgi_info attribute to the tuple
            (dir, rest) if self.path requires running a CGI script.
            Returns False otherwise.

            If any exception is raised, the caller should assume that
            self.path was rejected as invalid and act accordingly.

            The default implementation tests whether the normalized url
            path begins with one of the strings in self.cgi_directories
            (and the next character is a '/' or the end of the string).

            """

            splitpath = server._url_collapse_path_split(self.path)
            # more processing required due to possible PATHINFO parts
            # not clear above function really does what is needed here,
            # nor just how general it is!
            splitpath = '/'.join( splitpath ).split('/', 2 )
            head = '/' + splitpath[ 1 ]
            tail = splitpath[ 2 ]
            if head in self.cgi_directories:
                self.cgi_info = head, tail
                return True
            return False

I have no idea what applications might depend on the improper handling of PATH_INFO that the current code is performing, so that is why I applied my fix for that in my overridden code, rather than in the server.py source file.

It may be that the actual fix for this issue is in the overridden code above (but the fix to _url_collapse_path_split also seemed necessary, there was a corner case that it did incorrectly, but after 16 months, I couldn't tell you what that corner case was, any more.

Yes, the biggest issue here was the regression from 2.6, the security fix seemed to break the PATH_INFO feature.