I also agree with raising a UnsupportedMediaType and having custom handlers
for 400, 415 is always useful IMO
On Saturday, 12 November 2022 at 12:24:45 UTC Adam Johnson wrote:
> I would have a slight preference for raising an UnsupportedMediaType as
>> well and letting that percolate to a 415
>
> I would have a slight preference for raising an UnsupportedMediaType as
> well and letting that percolate to a 415 as it seems more correct from a
> content negotiation perspective.
Thinking about it again I think I have a slight preference too.
I guess this would warrant adding a urlconf
> DRF’s behaviour feels more correct to me, since it allows terser views
that don’t check the content type explicitly. But it’s less backwards
compatible. I’m not sure which I prefer.
Given the .data attribute would be a new feature of the request object I
assume we don't have any backward
This first-step solution is good with me. It will allow everyone to switch
to request.data (etc.). And there’d be a clear way to use your own logic to
set request.data if needed: write a middleware (or view decorator, view
class, etc.).
What should request.data be/do in the case of an unsupported
Hello Carlton,
This is not an area of the code base I'm heavily involved with but the
increment approach you are proposing over this lack of feature support for
basic content negotiation seems like a sane approach to gradually make the
landscape better in this area without trying to get
Hi all.
I'm looking for a high-level sanity check if you would.
I've been trying to see a way forward through a nest of issues around two
concrete proposals:
1. Adding "content negotiation" to the request object, allowing automatical
parsing of different content types, such as JSON, as well
