Senthil Kumaran <orsent...@gmail.com> added the comment: On Sat, Nov 20, 2010 at 07:09:58PM +0000, Jeremy Thurgood wrote: > There are two separate things here: the URL and the filesystem path. > The bug is that the fragment and query parameters are stripped in > translate_path(), but are *not* stripped when manipulating the URL > for the redirect.
Thanks for the explanation. My understanding of the bug (and the patch) is same as yours. > This means that when the URL is "/something?foo" and the cwd is Now, lets stop here for a moment to reflect the meaning of this URL. Here is the Query string article from Wikipedia: http://en.wikipedia.org/wiki/Query_string It gives a generic definition: A typical URL containing a query string is as follows: http://server/path/program?query_string When a server receives a request for such a page, it runs a program (if configured to do so), passing the query_string unchanged to the program. The question mark is used as a separator and is not part of the query string. Given this, in the URL /something?foo , can 'something' be a directory in the filesystem? To which program will query string be sent? ( You can say that a program by name index{.py,cgi,pl) inside the something directory *can* handle it, but I don't see such a practical scenario or CGI server configuration) - Same argument a #fragment_identifier. This is portion of webpage (anchor tag), a file. It cannot start immediately after a file-system directory path. In the http.server code, you will see that 301 redirection part is entered only when the last part is directory, but in cases where a?q and a#f, ('a' wont be a directory, so that redirection part is not entered at all). Let's come to some real world scenarios. Now, what happens when you type "http://bugs.python.org?10231"; [1] in your browser? According to this bug report, the server should 301 redirect it to "http://bugs.python.org/?10231";. If you try this, this does not happen. The browser (client) is in fact, changing it to the corrected URL (because the original is invalid) and the server is just ignoring the so called query portion). If you use, urllib2 to request the above [1], you will find that it will fail with 401 error. These are the reasons, why I consider this report is not really a bug. Any suggestions or thoughts on the explanation? In your attached patch, I think we should still be able to use some tests without any change in the http.server code. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10231> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
