We have a user making a POST to our webserver (windows server 2003, IIS 6). They get the full response from our webapp, but then IIS also responds with a "400 Bad Request". No other information is provided (yes I have friendly errors turned off).
At first, I thought maybe it was some middleware injecting a response in there. However, I was able to find the following in the HTTPSys error logs which confirms that it is coming from our server:
2013-08-09 23:36:40 11901 80 HTTP/0.0 Unparsed - 400 - BadRequest -
There are a whole slew of these errors piling up, and I have no idea why. Unparsed doesn't really tell me anything, so I don't have much to go on. I was able to get them to produce a wireshark trace, which shows that we are indeed responding with the full correct response and then appending a 400 bad request response. I copied their request EXACTLY from wireshark and tried it from my machine and of course, I can't reproduce it (I get the one valid response back).
So I am completely unable to reproduce the "Unparsed" error, I WAS however able to get two responses back from one request. I intentionally broke the line endings between the request headers and body and I got back a full correct response followed by "Bad Request (Invalid Verb)".
Two questions
1) Does anyone have any ideas as to how to produce an "Unparsed" error in HTTPsys logs? Any thoughts on how I might go about reproducing this?
2) WHY is IIS responding to a single request with two responses? Is that normal behavior, or indicative of a configuration error?
Thanks for anyone willing to offer help on this terrible headache!
Going to answer my own question here because I wouldn't wish this pain upon anyone else.
It turned out their POST had a slight error in content-length, I am thinking it wasn't including the final "\r\n" but whatever it is the count ended up being short by 2.
The reason this never showed up when I copied the exact request and sent it from my machine was that I wasn't properly closing the connection. For some reason, closing the connection with a FIN actually makes the difference and causes the 400 Bad Request.
Not sure why this happens, maybe the extra chars sent in the initial request are somehow read when the FIN comes? I don't know, but there you have it. Fix the content-length and the pain goes away.
Related
I‘ve read many times that, when HTTP 400 error code (Bad request) is raised, the client should not repeat the request.
I‘m wondering, if the request couldn‘t be completed, why is it that important the client does not repeat the request? Even though repeating the request wouldn‘t help fixing the error, it seems to be very significant that the client doesn‘t re-send the malformed request.
Why is that?
If a 400 bad request signifies that there was a client side issue, repeating the request would do nothing but waste the servers resources. Most of the time, a query param, header, or part of the body is incorrect, and the request needs to be physically changed to work. Some servers use 400 to show the request was recognized but not completed, but overall most cases need something to be physically changed. A 500 code shows that there was a SERVER side error, which is not the case here. A lot of the time, there will be a response body explaining the error along with the 400 code
The worst thing repeating the request will do is waste server resources since it’s not causing an error on the server, but is basically pointless in most cases to repeat.
If I am making an HTTP server, can I choose to ignore requests I don't want to respond to and let them time out?
I'm just wondering whether I am in any sense better off not responding to requests from potentially malicious sources than responding to them with data I'd rather not serve up, or responding with some 403 Forbidden or similar response that lets them know I exist.
A 403 should suffice. But I wouldn't let it just time out. If someone is trying to be cheeky, a time out will be more informative than a Service Unavailable 503.
I answered a relevant question a while back, read the question/answer, it's about a specific use case, but it does mention cases where you don't want to return an HTTP status code because it gives too much info.
RFC - 404 or 400 for relation of entity not found in PUT request
Also have a look at this list of HTTP Status codes, you can always use something like Too Many Requests 429, a Not Acceptable 406 or even something like I'm a teapot 418 ;)
I'm a student and I'm taking my first networking class. I'm working on an assignment designed to get me used to using Wireshark and understanding packet transfers. Part of the assignment is to collect some data about a certain GET request, but my Wireshark isn't showing anything related to GET or POST requests.
I've discussed this with my instructor and he can't figure it out, either. I've tried uninstalling/reinstalling Wireshark, but haven't gotten anything different.
Here's what I'm getting when I should be getting GET data:
26030 1157.859131000 128.119.245.12 10.0.0.7 HTTP 564 HTTP/1.1 404 Not Found (text/html)
This is the first packet I get after connecting to the server (this comes from right-click "copy"). From what I've gathered from the assignment instructions and the instructor, this should get a GET request. Anyone have any ideas?
You can use a browser plugin like firebug to examine actual request and response headers being exchanged. Sometimes due to page caching actual document may not be refetched after only headers like if modified since since being exchanged or the browsers cached version has not expired.
My scraping program usually works, but it occassionally gets a HTTP 400 error from the server. There is no lasting throttle effect; it goes back to working immediately after the 400 response.. I'd estimate that ~1/5000 of the responses I get are 400's, while the rest are success (200's). What could be going on.. anything I could do to eliminate these errors?
Http 400 is bad request.
There is something in the request that the server is reacting to. It will not affect any other requests.
A typical cause of this is special characters is a string.
Best way to fix it is to find the root cause, try logging all request if this is possible in your environment.
We have a REST API which clients routinely POST and PUT data to. When they do this, sometimes they POST data which results in no change on our system. The POSTs and PUTs are well-formed, but they data they're sending is identical to the data in our database. When this happens, I've just found out that we're returning a 400 HTTP status. Unfortunatly, this means "bad request" as in "request could not be understood by the server due to malformed syntax".
Clearly this is not the case, but I'm told that we're going to use this since there's no other appropriate status code. Choices we've considered:
304 Not Modified. This, regrettably, is only for GET requests.
204 No Content. Seems close, but forbids an entity-body.
Other choices seem equally bad. We might go with 200 OK and have the relevant information in the XML document we return, but this doesn't seem very "RESTish". How does the REST world generally handle this?
(Fixed Not Modified response code. Thanks Mkoeller)
I think it's perfectly fine to return a 200 OK in that case, the data was correctly processed and the server did what it had to. Because the server processed correctly the data, it should return an OK status code. The fact that it ignored it internally is or should be irrelevant.
What the server did to the data should not be told to the clients, they should be told what happened to the request (processed ok, error occurred, and the like).
And if, for some weird reason (I can't think a valid one, btw), it is of interest to the clients, you have the response to tell them so.
If the clients are able to know the entity tag for the content on the server before they PUT, then using If-Match headers and the 412 Precondition Failed response exists for exactly the situation you describe.
From client view the server status is the same if the request content was the same on the server or not, right? Since the server afterwards holds excactly the content that was sent, why should the server respond with any kind of error status?
On the other hand why should the client bother if the request content was the same as already known to the server? It was successfully transfered to the server so the bulk of work is done. How is a client expected to react if there was a different response code for this situation?
Conclusion: Your situation of a request content equaling the existing content is no special case. You should respond with the same response status code. That might be 200, 302 or 303.