Supply `url` property to `HttpResponseRedirect` and `HttpResponsePermanentRedirect`

[Ram Rachum]

Currently the way to get the URL that a HttpResponseRedirect is redirecting to requires doing response['Location']. This is not so intuitive. There's no reason to remember the HTML header name when dealing with a redirect response.

Instead I propose this property:

url = property(lambda self: self['Location'])

[Ram Rachum]

Sorry for the butchered Python, I meant:

    url = property(lambda self: self['Location'])

[Jannis Leidel]

Formatting updates.

[Ram Rachum]

What is needed now to add this to Django?

[Hiroki Kiyohara]

​https://github.com/django/django/pull/657

I opened a pull-request. Fixed the implementation and tests.

[anonymous]

I added the documentaiton and tests.

[Claude Paroz <claude@…>]

In e94f405d9499d310ef58b7409a98759a5f5512b0:

Fixed #18558 -- Added url property to HttpResponseRedirect*

Thanks coolRR for the report.

[Hiroki Kiyohara]

Thanks coolRR and claudep.
I am glad to contribute to Django at first time.

[Ram Rachum]

Thank you hirokiky and claudep!

[tevans]

Hi, I think this change is incorrect.

It makes HttpResponse(status=302, content='Foo') behave differently to HttpResponseRedirect(content='Foo').

This can be seen by using the test client, and asking it to follow redirects. It will attempt to access the url property on the response, but because the response is a redirect that is not derived from HttpResponseRedirectBase, this will fail.

[Claude Paroz]

HttpResponseRedirect(content='Foo') is not valid, the redirect_to parameter being mandatory. I think that the proper answer would be not to use a plain HttpResponse for an HTTP redirection. If you have a valid use case for using an HttpResponse(status=302) instead of an HttpResponseRedirect, please open a new ticket (where you can reference this one).

[tevans]

If creating a redirect manually from a HttpResponse is incorrect, why is it possible to create a HttpResponse with status 301, 302, 303 or 307?

The problem is that the test client uses both the API of HttpResponse to check whether the response is a redirect or not, and then it uses the API of HttpResponseRedirectBase to determine the redirection location. You think that is not a bug?

It only comes around because someone has decided that knowing the URL for a redirect is in the Location header is needless knowledge, it is better to instead learn a distinct API just for this framework. Also, lets make it so that that API prevents previously working and still currently documented as working code from being treated correctly, and ignore bug reports on it because pseudo code didn't have all the arguments specified.

Yay progress!