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

-- 
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/CAL79TckBT5gH4xd9xOouKHD21SQULz-yLtaUPa3k%3DT7sJshUZg%40mail.gmail.com.

Re: Feature Request: customize redirectable status codes in test client

['Adam Johnson' via Django developers (Contributions to Django itself)]

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  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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAL79TckBT5gH4xd9xOouKHD21SQULz-yLtaUPa3k%3DT7sJshUZg%40mail.gmail.com
> 
> .
>

-- 
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/CAMyDDM36oDsUp6ZrO54KxdDqvpCfZihBZQT3tKFkqhm9oakuCQ%40mail.gmail.com.

Re: Feature Request: customize redirectable status codes in test client

[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!

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  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
>>  
>> 
>> .
>>
>

-- 
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.

Re: Fellow Reports - February 2022

[Mariusz Felisiak]

Week ending February 20, 2022 

*Triaged: *
   https://code.djangoproject.com/ticket/33512 - Creating a child instance 
with a parent containing DateTimeField(auto_add_now=True) raises 
IntegrityError. (duplicate) 
   https://code.djangoproject.com/ticket/33505 - Inconsistent Behavior with 
Abstract Models and Signals (invalid) 
   https://code.djangoproject.com/ticket/33513 - Custom authentication 
class: raising AuthenticationFailed leads to 403 (invalid) 
   https://code.djangoproject.com/ticket/33514 - Fallback to a more generic 
language variant for Select2 translations. (accepted) 
   https://code.djangoproject.com/ticket/33515 - ManyToManyField to 
lowercased swappable setting causes generating infinite migrations. 
(accepted) 
   https://code.djangoproject.com/ticket/33518 - Add alias 
RemovedAfterNextVersionWarning for deprecations after next version 
(accepted) 
   https://code.djangoproject.com/ticket/33517 - Extracting seconds also 
returns fractional seconds on PostgreSQL. (accepted) 
   https://code.djangoproject.com/ticket/33519 - Recursive {% include %} 
crashes silently. (wontfix) 
   https://code.djangoproject.com/ticket/33521 - New tables are not created 
from the models (invalid) 
   https://code.djangoproject.com/ticket/33525 - decorator @html_safe 
removes completely old class.__str__ method. (wontfix) 
   https://code.djangoproject.com/ticket/33524 - ModelAdmin with defined 
radio_fields override empty_label (accepted) 
   https://code.djangoproject.com/ticket/33523 - remove dangerous text from 
translated message about csrf error (invalid) 
   https://code.djangoproject.com/ticket/33526 - Accept truthy/falsy values 
in security checks. (wontfix) 
   https://code.djangoproject.com/ticket/33527 - Remove unnecessary code in 
ModelAdmin._changeform_view(). (accepted) 
   https://code.djangoproject.com/ticket/33529 - Possibly Incorrect 
statement in the docs about CRSF tokens (invalid) 

*Reviewed/committed: *
   https://github.com/django/django/pull/15419 - Refs #25684 -- Removed 
double newline from request/response output of runserver. 
   https://github.com/django/django/pull/15425 - Refs #33348 -- Made 
SimpleTestCase.assertFormError()/assertFormsetErrors() raise an error for 
unbound forms/formsets. 
   https://github.com/django/django/pull/15426 - Refs #33348 -- Made 
SimpleTestCase.assertFormsetErrors() raise an error when form_index is too 
big. 
   https://github.com/django/django/pull/15427 - Refs #33348 -- Improved 
messages raised by SimpleTestCase.assertFormError()/assertFormsetErrors(). 
   https://github.com/django/django/pull/15428 - Refs #33348 -- Made 
SimpleTestCase.assertFormError() raise ValueError when "field" is passed 
without "form_index". 
   https://github.com/django/django/pull/15423 - Fixed #28358 -- Prevented 
LazyObject from mimicking nonexistent attributes. 
   https://github.com/django/django/pull/15415 - Made Field.error_messages 
a cached property. 
   https://github.com/django/django/pull/15434 - Refs #27468 -- Updated 
django.core.signing docstring. 
   https://github.com/django/django/pull/15435 - Refs #28358 -- Fixed 
infinite recursion in LazyObject.__getattribute__(). 
   https://github.com/django/django/pull/15438 - Fixed #33514 -- Added 
fallbacks to subsequent language codes in Select2 translations. 
   https://github.com/django/django/pull/15244 - Fixed #33379 -- Added 
minimum database version checks. 
   https://github.com/django/django/pull/15441 - Refs #33173 -- Fixed 
MailTests.test_backend_arg() on Windows and Python 3.11+. 

*Authored: *
   https://github.com/django/django/pull/15433 - Fixed #33515 -- Prevented 
recreation of migration for ManyToManyField to lowercased swappable 
setting. 
   https://github.com/django/django/pull/15443 - Refs #33526 -- Made 
CSRF_COOKIE_SECURE/SESSION_COOKIE_SECURE/SESSION_COOKIE_HTTPONLY don't pass 
on truthy values.

Best,
Mariusz

-- 
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/e4b08f13-a513-422c-8896-88cc9e028df9n%40googlegroups.com.