On Mon, Dec 5, 2011 at 2:00 PM, Cal Leeming [Simplicity Media Ltd] < [email protected]> wrote:
> Not sure if this should have a bug ticket raised or not.. wanted to get > core devs thoughts. > > > _redir = "//your/path/with/an/extra/slash/for/whatever/reason" > HttpResponseRedirect(_redir) > returns "Location: > http://your/path/with/an/extra/slash/for/whatever/reason"; > > _redir = "/your/path/with/no/extra/slash" > HttpResponseRedirect(_redir) > returns "Location: /your/path/with/no/extra/slash" > > It seems that if the URL has an extra slash on the start of it, > redirection doesn't work properly. > > Should this be classed as bad user sanity checking, or > HttpResponseRedirect() not being flexible enough? > > I personally feel it's not being flexible enough, but would be good to > hear your thoughts. > > Cal > Not a core dev, but I can offer my thoughts anyway :) First, your server should not ever be sending: Location: /your/path/with/no/scheme According to RFC2616, and to the comments in django/http/__init__.py, the Location header *must* contain an absolute URL. django.http.utils.fix_location_header is supposed to be called on every response, by the base WSGI handler, and should fix up any URLs that don't already start with 'http://' or 'https://'. If it doesn't include a host part (after a //), then Django should insert the name of the currently active host.[1] Second, a URL starting with a // is perfectly valid, and is supposed to represent a "scheme-relative" URL. ie., it includes the hostname, path, and query string; everything but the actual scheme (http: or https:) They're useful for constructing links to resources where you have to preserve https, if the current page is secure, (to prevent browser warnings, privacy leaks, security holes). There was some discussion on stack overflow last week on this[2]; it mostly relates to using // urls in markup, not in a header, though. I think the existing code is correct; my tests show that HttpResponseRedirect("//host/path/to/resource/") yields Location: http://host/path/to/resource/ and HttpResponseRedirect("/path/to/resource/") yields Location: http://127.0.0.1/path/to/resource/ In both cases, the response fixes have constructed the correct absolute url, based on what I used to construct the redirect. I think that if you're occasionally getting a double slash in front of your redirect urls, you should probably fix the code that is generating them, or create a new subclass of HttpResponseRedirect that eliminates the redundant character before adding the header. > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > [1] This used to be the value from the Host: request header, but I think recent security patches have changed that. [2] http://stackoverflow.com/questions/8343942/what-is-the-effect-of-starting-a-url-with-and-leaving-out-http (also referenced: http://stackoverflow.com/questions/4978235/absolute-urls-omitting-the-protocol-scheme-in-order-to-preserve-the-one-of-the and four or five other related questions) -- Regards, Ian Clelland <[email protected]> -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
