Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removing request content type configuration that cleans request data #27

Closed
wants to merge 1 commit into from

Conversation

SamambaMan
Copy link

After the execution of dispatch, the following code:
request.content_type = request.META.get('CONTENT_TYPE', 'text/plain')
The request contents (POST, body) are cleaned if the post is a multipart/form-data

@senko
Copy link
Member

senko commented Dec 9, 2016

@SamambaMan could you explain what this change does, ie. why you think that code is incorrect?

@SamambaMan
Copy link
Author

Senko, thanks for your attention.

When posting data, using multipart/form-data, if this code is executed request.POST is cleaned.

My method is:

from restless.views import Endpoint
class CadastroSplash(Endpoint):
    def post(self, request, idCampanha, **kwargs):

if I do a:

print request
print request.POST

I get a

<WSGIRequest: POST '/ambiente/alo/cadastrosplash/448/'>
<QueryDict: {}>

Configured my url patterns this way:


from django.views.decorators.csrf import ensure_csrf_cookie
from meuprojeto.meupacote.views import CadastroSplash

urlpatterns = [
    url(r'^cadastrosplash/(?P<idCampanha>\d{1,8})/$$',
         ensure_csrf_cookie(CadastroSplash.as_view())),
]

After removing that code all posts works correctly.

Is this the right fix?

(i'm running python-2.7, django 1.10 and djangorestless 0.0.10, all downloaded using pip)

Thanks in advance!

@senko
Copy link
Member

senko commented Dec 9, 2016

Have you tried accessing request.data ? The incoming data is parsed according to the content type and stored in request.data. Please see http://django-restless.readthedocs.io/en/latest/#restless.views.Endpoint for details

@SamambaMan
Copy link
Author

Sure, request. data is also cleaned.

A print request.data without the code comes with the data:

{u'Titulo': u'asdfasdf', u'FaixaEtaria': u'["4","5","6","7","8","9","10","11"]', u'TempoDeExibicao': u'5', u'SexoDirecionado': u'A'}

The same print with that line gets cleaned:

{}

A few more information, thought, i'm using django restless since django 1.5 and recently i'v just update my entire application to django 1.10.
I have a django restless based rest interface for third party service consumers and they worked just fine.
After this finel update of django and djangorestless this specific function stoped working.

Thanks!

@senko
Copy link
Member

senko commented Dec 9, 2016

Ah, so it stopped working after upgrading to 1.10? I see, that’s definitely something we need to fix, but it’s going to be more complicated than removing this line, because it’s needed to pre-process the data.

@SamambaMan
Copy link
Author

Senko, all right, i believe it may realy be more complicated than that.
How may I help?
Do you need more request information?
Form data generated from the browser?

My system is on staging and removing that line and running tests worked for me, i'm going to live production that way, no problem.
But I would love to help to fix this in any way i can.

Thanks!

@senko
Copy link
Member

senko commented Dec 9, 2016

I’ve taken a closer look and it seems that in Django 1.10, Django itself adds content_type attribute to HTTPRequest, with a slightly different semantics than restless, so in case of Django 1.10 and above, we shouldn’t set the content_type attribute.

However, for earlier Django versions, it’s still needed, so instead of simpliy removing it, we should check to see if we have it, and add if not. I’ve made the change in #28 and it seems to behave nicely in tests.

Can you check whether that branch works correctly for you?

@senko
Copy link
Member

senko commented Mar 22, 2017

Assuming this is solved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants