Feature Request: customize redirectable status codes in test client

[Clemens Wolff]

Hi Django Developers,

I'd like to discuss a change to the Django test client to enable customizing the list of status codes that are considered as redirectable when a GET request is made with `follow=True` (see docs in [1]).

Specifically, I suggest moving the `redirect_status_codes` property in the `_handle_redirects` method (see code in [2]) from a local variable to a class-level variable so that subclasses of the test client can override the collection to inject additional status codes on which to redirect.

This change will for example enable easy testing of APIs that use HTTP 202 to indicate asynchronous creation of entities as described in [3].

This is my first time reaching out to the mailing list. What do you think about this proposal? I'd be thrilled to submit a Trac ticket and pull request for this.

Thanks for your time and looking forward to hearing from you.
Yours,
Clemens

[1] https://docs.djangoproject.com/en/4.0/topics/testing/tools/#django.test.Client.get
[2] https://github.com/django/django/blob/fac3dd7f390d372736e05974cc5c3ef1a3768fbb/django/test/client.py#L962-L968
[3] https://docs.microsoft.com/en-us/azure/architecture/patterns/async-request-reply

[Adam Johnson]

202 is not a redirect, and I can’t find any standard that says where the “next” URL can be found. So I don’t think there is a strong argument to make the test client “follow” it or allow _handle_redirects to support it. You’re free to subclass the test client in your own project to add support - have you tried that?

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL79TckBT5gH4xd9xOouKHD21SQULz-yLtaUPa3k%3DT7sJshUZg%40mail.gmail.com.

[Clemens Wolff]

Thanks for the reply. Indeed, HTTP 202 isn't a redirect, but quite a few APIs use it as a "work in progress" indicator with a Location header to point to the resource to be created. This isn't a standard, just something I found in the wild a fair few times. One documented instance I stumbled across recently is on the Azure architecture cloud design patterns page but I can dig out more if required.

Regarding the point of subclassing the test client, that's exactly what I'd like to do. I'm not suggesting to add HTTP 202 as a default redirectable status code as this would likely break existing tests but instead to make it easier to subclass the test client by moving the list of status codes that the test client redirects to a class-level property. The list of redirectable status codes is currently hidden in the implementation of the `_handle_redirects` method so I'd need to override the entire method which is a lot of code to copy and likely will be brittle as it's a private method so there can be no expectation of continuity across releases. Moving the list of redirectable status codes to a class-level property would make it easier to customize the redirect behavior with a simple subclass like this:

```py

from django.test import Client

class MyCustomRedirectTestClient(Client):

    # this property customizes the redirect behavior:

    # instead of redirecting on HTTP 301/302/303/307/308

    # this client will only follow redirects on HTTP 202
    redirect_status_codes = (202, )
```

Hope this makes my suggestion clearer. Let me know what you think!

[Adam Johnson]

Sorry - I understood your proposal. I meant - have you already tried the more circuitous route of creating your own subclass with the Django of today? Any change to Django can only go out in the next major release, then you have to upgrade, so it might practically be a year before you can use it.

FWIW my library patchy can be used to modify the internal source code of functions: https://pypi.org/project/patchy/ . This may be of use to avoid copy-pasting a lot of code.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/81ffedb0-864b-48b5-ad88-db52bbfde95an%40googlegroups.com.

[Clemens Wolff]

Yes, I have implemented a subclass to get the functionality I need: currently I'm wrapping the get method in my subclass to inject the custom logic of checking for a 202. It works ok. I just was snooping around the framework code and figured that supporting this functionality would be even easier if the status codes were a class-level property and given that I've seen this 202 status code plus location header pattern in a few places I figured to ask. It's not an urgent need for me.

You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/Si_BYs-ROZ4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM3Xf4Bn6mC0uFdgcT4NGNEMPV4oaChX5qC2daCLLym6QQ%40mail.gmail.com.