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.
Related
I’m wondering if there is a general convention for this: When implementing a HTTP health check for any given application where you are not interested in any response body but just the status code, what would the default/expected endpoint look like?
Using a HEAD request - and returning 200 or 204 status code (which one of those?)
Using a GET with 204
something else?
As of my experience, people use mostly GET and 200. A health check wouldn't respond too much content, so no use of making a HEAD request. But this is mostly the case with a dedicated health check URL.
Today's cloud systems often use Kubernetes or OpenShift. They appear to use a GET request. I think they'll probably want to get a 200ish response code, so 200-299:
https://docs.openshift.com/enterprise/3.0/dev_guide/application_health.html
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
Another example, Drupal defines the HTTP response code to be 200:
https://www.drupal.org/project/health_check_url
In Oracle's Infrastructure-as-a-Service docs you can choose between GET and HEAD requests, but the default is HEAD:
https://docs.oracle.com/en-us/iaas/api/#/en/healthchecks/20180501/HttpMonitor/
Use a GET with 204 possibly supporting also HEAD with same status code
A HEAD should give the same response as GET but without response body, so you should first know/define what the GET response gives out in terms of headers (and status code), then, if you want, you can support also HEAD on the same endpoint, returning the same status, in this case 204.
Note that if GET employee/34 anwswers with 404 also HEAD must anwser with same code. That means one must do the same work as for GET: check if employee esists, set status etc. but must not write any response. Tomcat supports this automatically as it uses for HEAD request a response object that never writes to the "real" response, so one can use same code handling GET
For a check one may consider also TRACE but it produces a response body / output mirroring what you send to it, is different, I haven't seen implemented anywhere.
TRACE allows the client to see what is being received at the other
end of the request chain and use that data for testing or diagnostic
information.
I'm implementing a /_status/ endpoint which does some sanity checks on data in our database.
For example, we are collecting measurements and the status should go "bad" if the latest measurement is over an hour old.
I would like to point Pingdom at this URL to leverage their alerting infrastructure and tell us when something's wrong.
On a "good" status I will serve an HTML page with an HTTP 200 OK status. But what would an appropriate HTTP status code be for "bad"? Or would it be more correct not to convey this information via status code, but via HTML content instead?
Thanks!
Well... this is an old question, but I ended up here, so I thought I'd give my two cents here:
It seems pretty clear that a 2xx should be returned if all is OK
If health is not OK, I think it should return a 5xx result (4xx talks about the client being at fault in the request; 2xx and 3xx are all successful to some degree).
I think that a 5xx is correct because this is a special request that is answering about the state of the whole service. Also, because most Load Balancers offer liveliness checks based on response codes and not all offer a way to parse a more complex payload (other than perhaps a RegExp Match which can make the check brittle).
I agree with #Julien that a 500 (specifically) doesn't seem appropriate, and we've decided on 503 Service Unavailable.
503 seems to fit for a couple of reasons:
It's a 5xx family result code which indicates that something is going on on the server side.
It has a temporary nature to it indicating that it may recover.
We just had a similar discussion in our group. We decided for our purposes that the HTTP response codes should be reporting on your server's success or failure to honor the request. For a GET, this would mean whether or not you can respond with the requested resource. In this case, the requested resource is a health report, so as long as you're returning that successfully, it should be a 200 response.
We're returning JSON for our health check, with a top-level "isHealthy" field set to true or false. Our load balancer and other monitors will parse the JSON and use this field to determine if the system is healthy or not.
If you don't want to parse JSON in your monitors, you could try putting a custom response header to indicate binary health of the system, e.g., System-Health: true or System-Health: false. You might have better luck getting monitors which can check that.
If you really want to use a response code, I would recommend an additional endpoint called something like "health" which returns a "204 No Content" when healthy, and a "404 Not Found" when not healthy. In this case, the resource defined by the URL is, symbolically, the health of your system, and so if it's healthy, you can return a successful response. If it's unhealthy, then it's health can't be found, hence the 404.
If your data is 'bad' because there is a service failure (even if that is a backend job failing) then a HTTP 500 seems like a valid response. It indicates that something, somewhere is broken.
It isn't very specific, you're shrugging your shoulders and saying:
The 500 (Internal Server Error) status code indicates that the server
encountered an unexpected condition that prevented it from fulfilling
the request.
ietf rfc7231
If you ask for health and the server state is not healthy, I'm partial to 409 Conflict which "Indicates that the request could not be processed because of conflict in the current state of the resource" .
Some people might object that if you can respond then the request can be processed, but I disagree. Every error message is a response. The server defines resource semantics. If you ask for the good news resource and the server responds "here is bad news", it didn't give you what it defines to have offered at that resource.
In practice, it's much easier to say 2**="up" 4**="down" and pipe request counts into an availability metric and have a load balancer remove the server from its pool based on the response code. Coming up with ways to argue that "hey, we told you something, so 200 OK" just seems like missing the forrest for the trees to me.
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.
Client sends a POST or PUT request that includes the header:
Expect: 100-continue
The server responds with the status code:
100 Continue
What does the client send now? Does it send an entire request (the previously send request line and headers along with the previously NOT sent content)? Or does it only send the content?
I think it's the later, but I'm struggling to find concrete examples online. Thanks.
This should be all the information you need regarding the usage of a 100 Continue response.
In my experienced this is really used when you have a large request body. It could be considered to be roughly complementary to the HEAD method in relation to GET requests - fetch just the header information and not the body (usually) to reduce network load. 100 responses are used to determine whether the server will accept the request based purely on the headers - so that, for example, if you try and send a large POST/PUT request to a non-existent server resource it will result in a 404 before the entire request body has been sent.
So the short answer to your question is - yes, it's the latter. Although, you should always read the RFC for a complete picture. RFC2616 contains 99% of the information you would ever need to know about HTTP - there are some more recent RFCs that settle some ambiguities and offer a few small extensions to the protocol but off the top of my head I can't remember what they are.
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.