RawPostDataException with 0.6.8

[dmodin]

We see this error when doing a post after upgrading from 0.6.7 to 0.6.8:

/request_logging/middleware.py:166: in process_body
@property
    def body(self):
        if not hasattr(self, '_body'):
            if self._read_started:
>               raise RawPostDataException("You cannot access body after reading from request's data stream")
E               django.http.request.RawPostDataException: You cannot access body after reading from request's data stream

using django 2.2.1

[tclancy]

Is this happening on all requests or just some? It feels like this may be a setup issue.

[oneandonlyonebutyou]

I got this error too, the moment I used https://github.com/miki725/django-url-filter

Based on an old post I added :
REST_FRAMEWORK = {
"FORM_METHOD_OVERRIDE": None,
"FORM_CONTENT_OVERRIDE": None,
"FORM_CONTENTTYPE_OVERRIDE": None,
...}

Could you please investigate this Thanks.

[tclancy]

Can one of you provide a test case that causes the issue? Guessing something in #65 is causing the body to be read and we don't have a test covering the problem.

[tclancy]

@kennethjiang can you guys take a look at this to see if the last PR caused an error?

[dmodin]

I'm currently trying to do a test reproducing the error

…

________________________________ De : Tom Clancy <[email protected]> Envoyé : jeudi 2 mai 2019 23:11 À : Rhumbix/django-request-logging Cc : dmod1; Author Objet : Re: [Rhumbix/django-request-logging] RawPostDataException with 0.6.8 (#67) @kennethjiang<https://github.com/kennethjiang> can you guys take a look at this to see if the last PR caused an error? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#67 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AEK6UDEGVZMTFLKOSUKBRLDPTNKHNANCNFSM4HJ3PWPA>.

[dmodin]

Can't reproduce it easily in a clean project but I think the issue is when posting data including uploaded file

[therefromhere]

I've managed to reproduce the bug - see example project here: https://github.com/therefromhere/django_request_logging_bug

I think the django-request-logging tests need a bit of refactoring so they can accommodate an integration test like this?

Using the example project:

with
Django==2.2.1
django-request-logging==0.6.9

./manage.py test
Creating test database for alias 'default'...
System check identified no issues (0 silenced).
E
======================================================================
ERROR: test_bug (django_request_logging_bug.apps.bug.tests.MyTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/johnc/Projects/django_request_logging_bug/django_request_logging_bug/apps/bug/tests.py", line 8, in test_bug
    self.client.post("/bug/create/")
  File "/home/johnc/.virtualenvs/scratch_django_22/lib/python3.7/site-packages/django/test/client.py", line 543, in post
    response = super().post(path, data=data, content_type=content_type, secure=secure, **extra)
  File "/home/johnc/.virtualenvs/scratch_django_22/lib/python3.7/site-packages/django/test/client.py", line 357, in post
    secure=secure, **extra)
  File "/home/johnc/.virtualenvs/scratch_django_22/lib/python3.7/site-packages/django/test/client.py", line 422, in generic
    return self.request(**r)
  File "/home/johnc/.virtualenvs/scratch_django_22/lib/python3.7/site-packages/django/test/client.py", line 503, in request
    raise exc_value
  File "/home/johnc/.virtualenvs/scratch_django_22/lib/python3.7/site-packages/django/core/handlers/exception.py", line 34, in inner
    response = get_response(request)
  File "/home/johnc/.virtualenvs/scratch_django_22/lib/python3.7/site-packages/request_logging/middleware.py", line 99, in __call__
    self.process_body(request)
  File "/home/johnc/.virtualenvs/scratch_django_22/lib/python3.7/site-packages/request_logging/middleware.py", line 166, in process_body
    if not request.body:
  File "/home/johnc/.virtualenvs/scratch_django_22/lib/python3.7/site-packages/django/http/request.py", line 280, in body
    raise RawPostDataException("You cannot access body after reading from request's data stream")
django.http.request.RawPostDataException: You cannot access body after reading from request's data stream

----------------------------------------------------------------------
Ran 1 test in 0.021s

FAILED (errors=1)
Destroying test database for alias 'default'...

[fotometabata]

thank you.
Resolved after downgrade the "django-request-logging" version from 0.6.9 to 0.6.7

It seems that the version was upgraded because no version was specified in the "requirements.txt".

But, I did not understand the cause that would occur when 0.6.9. sorry.

[palmchou]

Same exact issue. Attached trace stack below.

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/django/core/handlers/exception.py", line 34, in inner
    response = get_response(request)
  File "/usr/local/lib/python3.6/site-packages/request_logging/middleware.py", line 99, in __call__
    self.process_body(request)
  File "/usr/local/lib/python3.6/site-packages/request_logging/middleware.py", line 166, in process_body
    if not request.body:
  File "/usr/local/lib/python3.6/site-packages/django/http/request.py", line 275, in body
    raise RawPostDataException("You cannot access body after reading from request's data stream")
django.http.request.RawPostDataException: You cannot access body after reading from request's data stream

In my case, the request is a POST as multipart/form with a file upload.

[kennethjiang]

@kennethjiang can you guys take a look at this to see if the last PR caused an error?

Sorry for missing your question @tclancy . We can't reproduce this problem here.

[therefromhere]

@kennethjiang did you try using the example project I linked above?

I think the bug is triggered by a POST that contains no form fields (eg of file only).

[wwsean08]

Working on this now and figuring out how to fix it

[krzysieqq]

Still in 0.7.1

[JocelynDelalande]

From my tests : I had the bug in 0.6.9, upgrading to 0.7.2 fixed it.

[krzysieqq]

Still in 0.7.3, problem doesn't exists in 0.7.2