--
Ticket URL: <https://code.djangoproject.com/ticket/33350>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Comment (by Carlton Gibson):
Hi Terence — Thanks for the report. Can you post a traceback quickly, or
better a reproduce? (But a traceback would be good.)
--
Ticket URL: <https://code.djangoproject.com/ticket/33350#comment:1>
* component: Uncategorized => HTTP handling
Comment:
3fd82a62415e748002435e7bad06b5017507777c for #32468 looks likely.
--
Ticket URL: <https://code.djangoproject.com/ticket/33350#comment:2>
Comment (by Carlton Gibson):
The check has been in sensitive_post_parameters
[https://github.com/django/django/blame/64839512a6ed04a29e49e246acf8337b1be2cb8e/django/views/decorators/debug.py#L80
for a long time].
--
Ticket URL: <https://code.djangoproject.com/ticket/33350#comment:3>
* status: assigned => closed
* resolution: => needsinfo
Comment:
I don't see how this can be a regression, these decorators use functions
from [https://docs.djangoproject.com/en/4.0/ref/utils/#module-
django.utils.cache django.utils.cache] which are documented as accepting
`HttpResponse` 🤔 Also `Response` defined in `django-rest-framework` is a
subclass of `HttpResponse`.
--
Ticket URL: <https://code.djangoproject.com/ticket/33350#comment:4>
* status: closed => new
* resolution: needsinfo =>
Comment:
Replying to [comment:4 Mariusz Felisiak]:
> I don't see how this can be a regression, these decorators use functions
from [https://docs.djangoproject.com/en/4.0/ref/utils/#module-
django.utils.cache django.utils.cache] which are documented as accepting
`HttpResponse` 🤔 Also `Response` defined in `django-rest-framework` is a
subclass of `HttpResponse`.
[https://github.com/encode/django-rest-
framework/blob/master/rest_framework/request.py#L140 Response] has never
inherited from `HttpResponse` which has been the source of many issues
like this even before 4.0. I am experiencing a lot of issues right now
converting Django method views into DRF class-based views right now
because all of the decorators keep breaking.
--
Ticket URL: <https://code.djangoproject.com/ticket/33350#comment:5>
* cc: Tom Christie, Carlton Gibson (added)
Comment:
Replying to [comment:5 jason]:
> [https://github.com/encode/django-rest-
framework/blob/master/rest_framework/request.py#L140 Request] has never
inherited from `HttpRequest` which has been the source of many issues like
this even before 4.0. I am experiencing a lot of issues right now
converting Django method views into DRF class-based views right now
because all of the decorators keep breaking.
Sorry, I confused `HttpRequest` with `HttpResponse`. Nevertheless, IMO, if
DRF is duck typing `HttpRequest` it should be fixed in DRF, e.g. by adding
`__instancecheck__()`. What do you think Tom? I'm happy to provide a patch
to DRF.
--
Ticket URL: <https://code.djangoproject.com/ticket/33350#comment:6>
Comment (by Carlton Gibson):
I think this is going to cause trouble for a lot of folks.
The `sensitive_post_parameters` has been as it is for many years, but the
[https://www.django-rest-framework.org/api-guide/caching/#using-cache-
with-apiview-and-viewsets caching usage is standard DRF]. (Again that's
been there a long time.)
The check in 3fd82a62415e748002435e7bad06b5017507777c seems overly tight.
What methods are being called?
Surely any Request-a-like exposing those is OK?
I don't think we can just change `Request` to claim to be a `HttpRequest`.
[https://github.com/encode/django-rest-
framework/blob/master/rest_framework/request.py#L154-L158 DRF has an
`isinstance()` check for this very thing].
Introduced in https://github.com/encode/django-rest-framework/pull/5618
See also:
- https://github.com/encode/django-rest-framework/issues/5446
- https://github.com/encode/django-rest-framework/issues/3848
(and others)
--
Ticket URL: <https://code.djangoproject.com/ticket/33350#comment:7>
Comment (by Mariusz Felisiak):
This error was added to catch misuses of `never_cache()` and
`cache_control()` decorators without `method_decorator()`.
--
Ticket URL: <https://code.djangoproject.com/ticket/33350#comment:8>
* has_patch: 1 => 0
* severity: Normal => Release blocker
* stage: Unreviewed => Accepted
Comment:
We've discussed this with Carlton, and see two possible solutions:
- allow for `HttpRequest` duck-typing, or
- changing errors to be based on missing `method_decorator()` call, maybe
checking that `request` is not a callable 🤔 or sth similar.
--
Ticket URL: <https://code.djangoproject.com/ticket/33350#comment:9>
--
Ticket URL: <https://code.djangoproject.com/ticket/33350#comment:10>
Comment (by jason):
Replying to [comment:8 Mariusz Felisiak]:
> This error was added to catch misuses of `never_cache()` and
`cache_control()` decorators without `method_decorator()`.
Breaking functionality in order to provide a nice error message seems
backwards.
Then again, I can't think of a good excuse for DRF not to simply inherit
from HttpRequest.
I recently fell down a rabbit-hole of github issues that were closed
without resolution regarding this conflict, where DRF refuses to inherit
because "composition pattern", and django refuses not to check because
"nice error message" over and over.
Something has to give right?
--
Ticket URL: <https://code.djangoproject.com/ticket/33350#comment:11>
Comment (by Mariusz Felisiak):
> Something has to give right?
This ticket is accepted. Have you seen my last
[https://code.djangoproject.com/ticket/33350#comment:9 comment]? We agreed
that this should be fixed in Django itself.
--
Ticket URL: <https://code.djangoproject.com/ticket/33350#comment:12>
Comment (by jason):
Replying to [comment:12 Mariusz Felisiak]:
> > Something has to give right?
>
> This ticket is accepted. Have you seen my last
[https://code.djangoproject.com/ticket/33350#comment:9 comment]? We agreed
that this should be fixed in Django itself.
Just saw it, don't mean to beat a dead horse, thank you for your quick
response ^_^
--
Ticket URL: <https://code.djangoproject.com/ticket/33350#comment:13>
* owner: Terence Honles => Mariusz Felisiak
* status: new => assigned
* has_patch: 0 => 1
Comment:
[https://github.com/django/django/pull/15206 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/33350#comment:14>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/33350#comment:15>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"40165eecc40f9e223702a41a0cb0958515bb1f82" 40165eec]:
{{{
#!CommitTicketReference repository=""
revision="40165eecc40f9e223702a41a0cb0958515bb1f82"
Fixed #33350 -- Reallowed using cache decorators with duck-typed
HttpRequest.
Regression in 3fd82a62415e748002435e7bad06b5017507777c.
Thanks Terence Honles for the report.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/33350#comment:16>
Comment (by Mariusz Felisiak <felisiak.mariusz@…>):
In [changeset:"c1d2e8b9b8f41d3effef03badc78c8b8995a99b6" c1d2e8b]:
{{{
#!CommitTicketReference repository=""
revision="c1d2e8b9b8f41d3effef03badc78c8b8995a99b6"
[4.0.x] Fixed #33350 -- Reallowed using cache decorators with duck-typed
HttpRequest.
Regression in 3fd82a62415e748002435e7bad06b5017507777c.
Thanks Terence Honles for the report.
Backport of 40165eecc40f9e223702a41a0cb0958515bb1f82 from main
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/33350#comment:17>