On Sun, Jan 1, 2023 at 7:01 PM Tim Graham <timogra...@gmail.com> wrote: > Incidentally, I don't think it's important for the ultimate decision here, > but I looked at the below analysis of ticket #32189. Carlton's analysis on > the ticket that request.POST is empty when using 'content-type': > 'application/json' remains true.
The bug report specifically says: > First due to the limitation in reading from FakePayload, in the real world > you can ask to read more just you would not read more i think > I found http request was setting a high chunk size for an unrelated test and > failing to read from fake payload > > Then i notice that when trying to use a content type json not multipart > (default) that the post data was empty again! > This time it seemed to be due to handling of application / json content I read that as clearly saying that the reporter's earlier attempt(s) *did* encounter the same bug as #34063, since otherwise why mention the read/chunk size and the mechanics of reading from FakePayload? It seems like a later attempt ran into the separate issue of the application/json content type not populating request.POST. Ideally this bug report would have been followed up with a "wait, why did it hit that code path with the read size error" during triage, since that is *not* what ought to be happening, even when request.POST is inappropriately accessed on a non-form request (request.POST should just be an empty QueryDict in that case). So I do believe #32189 is a duplicate of #34063. It just happened that the reporter had hit multiple issues: one was user error, but the other was a genuine bug in Django. > If I encountered a similar issue, I would have just worked around it and > moved on. Surely there are other issues like this one that don't meet the > current backport criteria but that could be similarly argued by someone > persistent enough. It would be nice if the outcome here avoided that in the > future. As I keep saying: for a feature as hyped up as async, and for a bug of this severity in the async testing support, I do not think Django can afford such a lackadaisical "work around it yourself" policy without incurring significant reputational harm. Nor can the response be that people should just upgrade -- mostly because Django should have fixed this bug two years ago, but even today Django should take responsibility for the bug and provide a backport of the fix into all the supported releases. And especially should do so since it *still* is not possible, today, to "upgrade" to a released version of Django containing the fix. > I guess it's nice to have a strict backport policy, partly to avoid hours of > discussion like this The fix could have been backported and released a dozen times over, and the backport policy amended with language to explicitly allow fixes like this one but not open the floodgates to anything and everything, in the amount of time that has been devoted to trying to prevent this from being backported. At any rate, your remaining objections basically seem to boil down to not liking the time and effort being spent on this. I have already offered to do whatever work is needed to see the backports through to release. It is not a particularly difficult patch, so far as I can tell, and I have significant direct experience backporting and maintaining much gnarlier bugfixes in branches of Django. So the time/effort objection is moot. -- 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/CAL13Cg_yTXKx7GRYuzqhiUZ%3Dy%3DbJesD%3D9TGjrjei6a_4D0SLfQ%40mail.gmail.com.
