Giter VIP home page Giter VIP logo

Comments (7)

nick2k5 avatar nick2k5 commented on June 21, 2024

Hm, yeah this is a problem. I've played around here and I can't find any great solutions that don't feel really slimy. Any thoughts @croach

from django-simple-rest.

croach avatar croach commented on June 21, 2024

@nick2k5 the explanation below is a little long winded and goes into an addition to the framework that would help alleviate some of the problems, so you can skip to the end to get the tl;dr version of the answer if you want.

Basically, it looks like Django is moving more and more into the modern era of web development. In the past nearly everything sent to the server came via a form submission, so it was a fairly safe assumption that all data sent in an HTTP POST was of the format sent by an HTML form. However, that's no longer the case. It's now very plausible that data is sent to the server via an HTTP POST using any number of media types (e.g., JSON).

With this new change, the maintainers of Django are basically saying that they are no longer making an assumption of what type of data is being sent, but instead they are relying solely on the Content-type header to tell them what the media type is. So, if the Content-type is set to application/www-form-urlencoded, then it will parse it as HTML form data and put the resultant data into the POST QueryDict. If, however, the Content-type is not specified, or is something else other than regular HTML form data, it will place the raw data into the raw_post_data attribute and leave the parsing of that data up to the developer.

So, given all of this, it looks like both Django and the framework are acting correctly. If you send data via an HTML form, the data will end up in the POST QueryDict since the default Content-type the browser sets is application/www-form-urlencoded. The problem occurs only when data is POSTed via some other mechanism (e.g., JavaScript or a non-web client). In this case, the solution is just to set the Content-type to application/www-form-urlencoded before sending the data, which is what we should be doing anyway, but have gotten away with not doing it up until now due to Django's lax handling of POST data in the past.

There is one thing that would be nice to add to the framework and that would be handlers for media types other than the ones that Django handles (i.e., file uploads and form submissions). So, for example, if you wanted to accept JSON data, the client could set the Content-type to application/json, send it, and the framework would call the JSON parser to convert the data into a python dict. Then that could be added to the POST QueryDict instead of leaving it up to the developer to parse the data from the raw_post_data attribute. This would still mean that the developer would have to correctly set the Content-type before sending the data, and so probably would not help in this case since I'm sure the reason the data isn't showing up in POST now is due to the lack of a Content-type rather than an unsupported one.

tl;dr This is the correct behavior. In the past Django has been too lax on how it handles POST data and has just assumed that all POST data comes from a form submission. This is no longer a valid assumption in this modern era of single page web apps and RESTful APIs, so Django has tightened its handling of POST data. To make sure that your data shows up in the POST QueryDict, simply make sure that the Content-type header is set to application/www-form-urlencoded before POSTing the data to the server.

from django-simple-rest.

nick2k5 avatar nick2k5 commented on June 21, 2024

@croach Thanks for this. Looks like a reasonable requirement (to require the header be set appropriately) -- I will add this to the docs.

from django-simple-rest.

nik-hil avatar nik-hil commented on June 21, 2024

@croach thanks for this. saved my day. Also learnt few bytes.

from django-simple-rest.

jjmontesl avatar jjmontesl commented on June 21, 2024

Should this issue be closed?

from django-simple-rest.

ppo avatar ppo commented on June 21, 2024

I guess it can now.

from django-simple-rest.

rasheedh avatar rasheedh commented on June 21, 2024

Thanks a lot.

from django-simple-rest.

Related Issues (12)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.