[Feature Request] Allow DeleteView to override the redirect to use 303

[kimsia]

I use class based view for delete.

1. Send a DELETE
2. then deleteview want to redirect using 302 after success delete
3. 302 will use precedent method and list typically don't accept DELETE as precedent method. Only POST, GET, and HEAD as precedent method

Most web frameworks (see ​https://stackoverflow.com/a/24375475/80353 for Java Spring e.g. for similar incident) adopt the convention of using 302 and 302 not allow DELETE as precedent method.

There are 3 solutions with drawbacks:

1. override the convention

Allow the backend web framework to accept DELETE as precedent method for 302.

Con: Not nice by convention

2. Let client handle redirection

send back a 200 then client will redirect back to list view

Con: This results in two requests and htmx-delete doesn't work that way. It will send a DELETE method request and then take whatever comes back and immediately swap. I like this so I want to keep this. One request to settle this rather than two.

3. Use 303 for the redirection

After successful delete, do a 303 redirect to list view (I chose this)

Con: 303 doesn't work with HTTP/1.0 and older browsers. But that's not a problem in the year 2021 and will continue to be less of a problem going forward.

Since I chose 303, I have to write my own delete view instead of override the original deleteview. My request is to allow the redirect to use 303 in a simple way. Kinda like how CBV can set certain class attributes like model, modelform

[Carlton Gibson]

Hi, no sorry — I don't think any extra API is worth the added complexity here. Override delete() and return the response you want. It's four lines.

See also the discussion on #21936 — the interplay between DeleteView and DeletionMixin is already too complicated and confused. We want to (radically) simplify that (if we're able to given backwards compatibility concerns) before we'll consider any expansions. I hope that makes sense.