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. On Sun, Feb 20, 2022 at 7:04 PM Clemens Wolff <clemens.wo...@gmail.com> wrote: > 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 > <https://docs.microsoft.com/en-us/azure/architecture/patterns/async-request-reply#solution> > 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! > > On Sunday, February 20, 2022 at 10:54:20 AM UTC-5 Adam Johnson wrote: > >> 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? >> >> >> On Sun, 20 Feb 2022 at 04:21, Clemens Wolff <clemen...@gmail.com> wrote: >> >>> 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 >>> >>> >>> -- >>> 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 >>> <https://groups.google.com/d/msgid/django-developers/CAL79TckBT5gH4xd9xOouKHD21SQULz-yLtaUPa3k%3DT7sJshUZg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/81ffedb0-864b-48b5-ad88-db52bbfde95an%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/81ffedb0-864b-48b5-ad88-db52bbfde95an%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM3Xf4Bn6mC0uFdgcT4NGNEMPV4oaChX5qC2daCLLym6QQ%40mail.gmail.com.
