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.
Related
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?
I'm running a site with Django and I only have access to the backend.
When I delete an item through the web interface (an alert) the DELETE request is run twice:
/alerts/[alert_id]
Request Method: DELETE
Status Code: 301 Moved Permanently
then
/alerts/[alert_id]/
Request Method: DELETE
Status Code: 204 No Content
Any thoughts as to where the issue could be or why it does this? Apparently the frontend only calls the request that ends with a slash (the second one)
My bad, the docs explained the problem, I just didn't know what I was looking for
if the request URL does not match any of the patterns in the URLconf and it doesn’t end in a slash, an HTTP redirect is issued to the same URL with a slash appended.
The HTTP 204 No Content success status response code indicates that the request has succeeded, but that the client doesn't need to go away from its current page. A 204 response is cacheable by default. An ETag header is included in such a response.
The common use case is to return 204 as a result of a PUT request, updating a resource, without changing the current content of the page displayed to the user.
Source file
Using Postman, when I make a PUT request to an endpoint which returns a 204 with content, Postman is unable to parse the response, and my collection runner stops that iteration, indicating that an error has occurred.
When run outside of the runner, Postman displays the following:
Other people have also had this problem
Unfortunately I cannot fix the non-standard endpoint. Is there a workaround that will let Postman continue without throwing an error, especially when using the collection runner?
The 204 (204 NO CONTENT) response from the server means that the server processed your request successfully and a response is not needed.
More here: https://httpstatuses.com/204
Actually as much as I know, if the server is sending a 204 with a payload response, the endpoint is not developed as it should.
This would be the main reason Postman is not showing a response payload. You will only be able to read response headers.
So if you send a PUT request, and only receive headers, it means everything is ok. If you spect data the server should be responding with a 200 code.
Now, said this, if postman is telling you that “it could not get any response” it means basically the server is not responding any thing. Now try to increase the timeout in the postman settings. It’s very probable that the server is taking to much time. Check outside the runner how much time it’s taking to response.
I hope this helps you.
[SOLVED] Please see my answer.
Any POST request sent with the
Content-Type: multipart/form-data; boundary=xYzZY results in the request.POST QueryDict{} to be empty. Changing the Content-Type to multipart/form-data also results in the same error.
Removing the Content-Type altogether results in the values getting passed correctly, and I can access them in request.POST.
I have tried disabling the Csrf middleware, using #csrf_exempt, and also tried the same on multiple servers. Didn't change the empty POST condition.
While reading up on Django framework and POST content-type, I read that it (no longer) assumes a default content-type and therefore must be supplied with the correct one (I do not have a link to the article in question.) I think something similar is happening here, with django not being able to parse the parameters with the given content-type (but leaving it blank lets the parser interpret it with the default value).
What I am having trouble with is, that the Content-Type value supplied is perfectly valid (multipart/form-data with boundary). So why does django refuse to load it in the POST dictionary?
** I am not in control of the Content-Type sent in the POST data.
** UPDATE: reading from request.body shows that all the POST parameters are being received. They're just not present in request.POST
** UPDATE: I'm using Runscope to test POST requests.
As mentioned in the UPDATE, I was using Runscope to test the POST data. I realised that the error was with the way Runscope handled multipart/form-data. I raised the issue with support and got notified that Runscope does not support multipart as of now. I've copied the relevant information here:
We hope to support multipart form uploads capabilities for the future, but don't have a timeline on when this will be available. Some customers have made this work in their Radar tests (https://www.runscope.com/docs/radar) by pasting in the raw multipart-formatted body or unicode string input body into the request and making sure to include the applicable 'Content-type' header value with the correct boundaries. Some examples for building a multipart/form-data POST request can be found here: http://chxo.com/be2/20050724_93bf.html
For Runscope URLs, multipart data is passed through unmodified. However, the request editor and retries from the Traffic Inspector (https://www.runscope.com/docs/inspector) do not currently support multipart data which is why your request retry did not work. Additionally, request and response bodies larger than 1 MB are not saved for viewing after the request has been sent.
Using another service solved this for me.
You are (in a manner) in control of Content-Type. What you're looking for is enctype. You can use it as following:
<form method="POST" action="." enctype="multipart/form-data">
enctype is only required when you are uploading a file, otherwise, it's not.
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