I'm submitting a POST using ajax clientside. It works fine whenever all the requests are valid. However, when I send a POST request to an invalid URL, and then follow it up with another POST request, regardless of whether it's valid, Django processes the request in a completely different manner. Before changing some code it was actually causing the server to crash.
Heres what happens in the Django server stdout when I send two invalid requests in a row:
Not Found: /profile/add_favorite
[01/Aug/2019 15:42:25] "POST /profile/add_favorite HTTP/1.1" 404 4132
Not Found: /profile/add_favorite
[01/Aug/2019 15:42:30] "title=Video+TitlePOST /profile/add_favorite HTTP/1.1" 404 4178
The second request looks ill-formatted, and it's of a different format than the previous request.
The request was sent using basic Ajax:
var conf = {
type: 'POST',
url: url,
data: {title: "Video Title"},
headers: {'X-CSRFToken': csrftoken},
}
$.ajax(conf)
And in the dev tools I checked that the requests were the same:
That's just the headers but the data is also the same. Anyways, the exact same code was used for both request. This only happens when I send a request to an invalid URL and then send another request after it, and if I reload the page after sending an invalid request and send another request that request will work like it should, but not without returning a messed up response first.
Behold: If I send a post request to an invalid URL and then reload the page in Chrome chrome will not send a valid GET request, instead it sends a request with the same prepended title, the same invalid format!
[01/Aug/2019 16:04:03] "title=Video TitleGET / HTTP/1.1" 403 2513
Then that's the issue:
Whenever I send an invalid url Ajax request from my browser, the next request to my server will be made invalid in the same way. I feel sure it's not a browser-side issue, because I can send an incorrect request from one window, and then the next request from a different window will be incorrect! This is the screen from that next request:
The CSRF token shouldn't even matter the first time a site is loaded, making this message nonsensical.
This is obviously an problem of incredible magnitude for my server, as any time a person sends a request to an invalid URL at my server then the next request will not process correctly.
This must be a bug with the Django development server? What could possibly cause this?
Related
Using Postman Version 6.4.4 (6.4.4), on MAC, i am not able to run any of the post request which was working for previous releases.
I keep getting the following similar exception from my middleware. THe issue is not with my middleware as the same request are working when invoked from my app.
The value 146 in the Content-Length request header is > than the
actual number of bytes in request body. Resend the request with the
correct content length
I tried to add 'Content-Length' to the header with some values < what is returned in the exception, in which case the request goes through but the request body is always empty.
After sucessfully updating an ember-data model, ember-data sends an OPTIONS request.
First of all, I would like to know why it sends an OPTIONS request.
And the actual problem is, that this options request is sent to the "location" where the put request returned from. Which is problematic because, I am using grunt-proxy and forward my requests to another domain. But the response from my PUT of course has this "other" domain as location. And the OPTIONS request ist then sent directly to this domain, which is of course not working due to CORS requests.
Additional Comment:
I found out that my PUT request returns a 302 Temporarily moved. I have to be honest, I have no idea, why because when I request my put Endpoint directly with some data, I never get a 302, always 204.
Could this be the reason why ember-data making the OPTIONS request?
I have a VB.NET app that sends a POST request to a script on my server that is running Cloudflare. I always get an error when sending the request from the app, however using a Firefox extension to simulate the request works fine. With the use of Fiddler I think I have found the cause of the problem:
When sending the request with the Firefox addon an extra header is attached to the request:
Cookie: __cfduidxxxxxxxxxxxx
This cookie is from Cloudflare, but where does it come from, ie. how can I get this cookie value and send it with my requests from the VB app? I tried copying and pasting the cookie into the app and it worked fine, so this leads me to conclude that I need this cookie, however this value is unique for each user so I cannot simply hardcode it into the app.
Quick side-note: Not sure if this helps, but if I send a GET request from the VB app it works fine without the __cfduid cookie.
Look for a Set-Cookie header coming back from the server on it's response. It will expect to get that value back on subsequent requests in a Cookie: header. This value is usually an opaque string that is classified by a path, although not always.
Whenever I add the "range" header in a HTTP request for a .cfm or .cfc file on my server, I get a timeout. The server simply does not respond.
To debug, I created a blank file called "/signup/test.cfm" on my server. It contains nothing. Next, I make a normal request and an edited request for the file:
Request:
GET /signup/test.cfm HTTP/1.1
Host: site.com
Response:
HTTP/1.1 200 OK
Request:
GET /signup/test.cfm HTTP/1.1
Host: site.com
Range: bytes=0-40960
Response:
timeout in transmission from site.com
If I include the Range header in a request to a static file, there is no problem.
What could be causing this, and how do I debug it? The file I am requesting is empty, so no code should be executing. Application.cfc is empty. Since I assume no code is executing, does this mean that it is a server configuration problem?
EDIT: By adding a tag to my script, I have confirmed that it does execute the ColdFusion code. The response is just never sent back to me.
Most likely the cf parser doesn't work with ranged requests while the static file handler does.
Range is for fetching part of content and subsequently fetching more later. E.g. Video file streaming or download continuation. Not something easily handled by a script handler as the request is meant to be returned all at once.
Here's a stackoverflow with a sample range request to show how this works
Sample http range request session
I am trying to implement django-paypal (dcramers version from git) using PDT with subscriptions.
It works fine (meaning that the return_url is requested and answered), however signals are not triggered (put in models.py). I am using the following signals, connected to two different functions.
from paypal.standard.pdt.signals import pdt_successful, pdt_failed
What I noticed while browsing through my access logs is that I do get a POST request from paypal which is turned down.
"POST /an-obscure-string/pdt/ HTTP/1.0" 401 401 "-" "-"
I tried to modify /paypal/standard/pdt/views.py to accept POST requests but I still get the 401 error. I think this is the reason signals are not triggered.
I am having a bad time with this. Any help would be greatly appreciated.
PS: I am using the sandbox account
EDIT These are my PAYPAL POSTBACK values from conf.py
POSTBACK_ENDPOINT = "https://www.paypal.com/cgi-bin/webscr"
SANDBOX_POSTBACK_ENDPOINT = "https://www.sandbox.paypal.com/cgi-bin/webscr"
You are right, that is the reason why the signal does not get called since signals are sent at the very end of the view if the model's verify succeed.
Your solution is indeed wrong, Paypal will definitely send a GET request with the transaction ID to your app url if you choosed to use PDN.
https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/howto_html_paymentdatatransfer
I really suggest you to check your settings (on paypal account) since you are probably using IPN which uses POST requests.
Another possible cause of this is that after you received the GET request from paypal your app sends the POST data to your app instead of to paypal postback endpoint. (https://github.com/johnboxall/django-paypal/blob/master/standard/pdt/models.py#L47)
I would look at the access logs to see if the POST request comes after a GET request (for the same url), if yes I would check the value of the SANDBOX_POSTBACK_ENDPOINT and POSTBACK_ENDPOINT settings.