RawPostDataException when trying to test IPN

[dantium]

I am using the chrome plugin Postman to try and test the IPN callback on my localhost. When posting to the callback URL I am getting a RawPostDataException error "You cannot access body after reading from request's data stream"

Am I doing something wrong here or is there a better why to test the IPN callback locally? Thanks

[spookylukey]

You'll need to paste the complete traceback. Thanks!

I suspect you have something (e.g. middleware or custom view logic) that is reading the request data, instead of letting the ipn view do that.

You can use the PayPal sandbox and something like ngrok to test locally.

[spookylukey]

I can't do anything without a traceback, so closing. Please reopen if you can provide more information.

[asfaltboy]

I just encountered the same issue and would like to share my insights and the workaround.

tl;dr django.test.Client requests default to the Content-Type=multipart/form-data, this prevents the ipn view from accessing request.body after it accesses request.POST. To work around it, pass a non-multipart content_type:

client = django.test.Client()
client.post(reverse('paypal-ipn'), data=ipn_data, content_type='application/x-www-form-urlencoded')

I found the issue encode/django-rest-framework#2774 extremely useful when debugging.

It is mentioned by Preston Holmes in a comment that Django prevents reading a body of a request with the multipart/form-data content type because "we don't want to repeat the expensive operation of parsing the multipart data".

While I'm fairly happy with the workaround, I'd hate to waste other users' time. So I would suggest we either:

1. Catch the RawPostDataException in the view (add try/except ~ L45 and present a sane error which states we expect the POST to have Content-Type: application/x-www-form-urlencoded, and it is something else).
2. Copy the request.POST/body before the first call and use the copy thereafter.

@spookylukey please let me know if you'd like to see a PR for either.

On a side note, it would be very helpful if Django docs mention the above behavior. I could not find mention of this anywhere besides this related middleware warning. Though the docstring added in this commit is very informative; I would go ahead and copy paste this directly to a warning in HttpRequest docs. I've expressed my last paragraph in this Django ticket.

[spookylukey]

Given that the PayPal docs explicitly show x-www-form-urlencoded (see https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNIntro/#a-sample-ipn-message-and-response ) I think the best option here is to first check that the Content-Type matches that, and raise an exception otherwise. This avoids using internals like RawPostDataException

[asfaltboy]

@spookylukey thanks for the quick response. I honestly couldn't find any mention (in quoted docs or any others) of the headers paypal sends. Right now however, the value of Content-Type is clearly x-www-form-urlencoded as can be seen by issuing a IPN Simulator request. And raising an exception if the behavior changes is a good way as any to handle this.

[jTiKey]

Is there a possibility this was changes recently? The server is getting many errors on the live server:
AssertionError: Invalid Content-Type - PayPal is only expected to use application/x-www-form-urlencoded. If using django's test Client, set content_type explicitly

[spookylukey]

@jTiKey If PayPal changed the data to no longer match what their docs show - https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNIntro/#a-sample-ipn-message-and-response - then you should take it up with them. I don't know if they have changed anything recently.