I've been writing an application this evening to add the Atom Publishing Protocol to my blog and some other projects I have in mind and hit a problem that I now realise Hugo, and no doubt others, have stumbled across in the past, too: Django wants to treat all incoming HTTP as though it was a form submission.
We detect multipart submissions to get at file uploads. But everything else is run through cgi.parse_qsl(). It seems like correct handling is that that should only be done for application/x-www-form-urlencoded MIME types (maybe I haven't got the full set right; too late at night to go read all the specs now). For things like applications/atomserv+xml and related ones (basically, everything else), data should be left unprocessed by the Django layers, I would have thought. For example, an Atom publishing request contains XML data that can't be treated like a form. And the application needs access to the raw data to process it. The fix I have in mind is to add a "data" attribute to the request object that contains the unprocessed data in cases like this and NOT put the data into the POST dictionary unless it really is form-encoded (since we are treating that as a FORM dictionary, rather than a POST dictionary). But I wanted to find out if there was a reason for this behaviour in the original design (Adrian? Jacob? Simon?). Did you have something in mind to work around it? Or was it a case of "never came up before"? Coincidentally, with Jacob working on some serializer stuff, I suspect he may be encountering the same problems at the moment, so this could be fortuitous timing. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
