I am developing both client and server. During development, I would the server to detect when the client appears to be buggy (send invalid data, omits mandatory parameter, etc, etc).
Is there a standard HTTP response code to indicate this? Or several, depending on the nature of the bug?
Or should I just use my own response code?
e.g 2001 I'm afraid I can't do that, Dave?
or 666 Mwuuuuuuhahhahahahahahahaha
HTTP 400 "Bad Request"
https://www.rfc-editor.org/rfc/rfc7231#section-6.5.1
The 400 (Bad Request) status code indicates that the server cannot or
will not process the request due to something that is perceived to be
a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing).
Related
I have used the websocket open connection sampler request in my project.
URL: wss://sip-qa.forestreettelco.com:11443
while executing the jmeter script getting the Response message:"http upgrade failed with status code 400"
Please help me.enter image description here
As per HTTP Status Code 400 description
The HyperText Transfer Protocol (HTTP) 400 Bad Request response status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
So my expectation is that you're sending the wrong request which doesn't match what your server expects. As it is not publicly available I cannot come up with the proper configuration, however I believe you should start with normal HTTP Request sampler and add the following Headers to the request:
Connection: Upgrade
Upgrade: websocket
Whatever other headers which real browser sends like Sec-WebSocket-Protocol, Sec-WebSocket-Version, Sec-WebSocket-Key, etc.
The headers can be added using HTTP Header Manager
You can capture browser traffic using built-in browser developer tools or an external sniffer tool like Wireshark.
Once you will be sending the same sequence of the same requests you should get the same responses as for the real browser.
I have given two url in csv file and trying to load that in jmeter. I am getting 503 response code.
As per HTTP 503 status code description
The HyperText Transfer Protocol (HTTP) 503 Service Unavailable server error response code indicates that the server is not ready to handle the request.
Common causes are a server that is down for maintenance or that is overloaded. This response should be used for temporary conditions and the Retry-After HTTP header should, if possible, contain the estimated time for the recovery of the service.
Note: together with this response, a user-friendly page explaining the problem should be sent.
Caching-related headers that are sent along with this response should be taken care of, as a 503 status is often a temporary condition and responses shouldn't usually be cached.
So I can think of at least 3 possible issues:
Your server is really overloaded, you can try checking Response Data tab of the View Results Tree listener - if you're lucky - you will the the aforementioned "user-friendly page explaining the problem"
Your request is malformed and server is sending 503 response instead of 4xx which indicates client-side error. Double check what URL(s) you're trying to open by looking into Request tab of the View Results Tree listener and try to open it in the browser. If you're building the URL from parts (i.e. host, port, protocol, query string, etc.) - you might want to check if the values are correctly read from the CSV file using Debug Sampler
I fail to see HTTP Header Manager in your Test Plan, some servers check the client Headers, for example User-Agent or Accept and may report an error if the required header is missing (i.e. indicating that the browser is not supported)
I have a WebSocket server written which only handles upgrade requests which are GET requests. If a POST or any other kind of request with the required headers comes it is handled by a HTTP server.
In the specification it is not stated explicitly that the WebSocket upgrade request should be a GET request.
If the upgrade request is not a GET request should the server handle it as a WebSocket upgrade request, should it pass it to be handled by the HTTP server or should it respond to it with a status code like 400 Bad Request ?
Could this be a design decision where the server decides not to handle methods which are not GET requests?
From section 4.1 (Client Requirements) of the webSocket specification, it says this:
The method of the request MUST be GET, and the HTTP version MUST
be at least 1.1
And, then later in section 4.2.1 (Reading the Client's Opening Handshake) of the webSocket specification, it says this:
The client's opening handshake consists of the following parts. If
the server, while reading the handshake, finds that the client did
not send a handshake that matches the description below (note that as
per [RFC2616], the order of the header fields is not important),
including but not limited to any violations of the ABNF grammar
specified for the components of the handshake, the server MUST stop
processing the client's handshake and return an HTTP response with an
appropriate error code (such as 400 Bad Request).
An HTTP/1.1 or higher GET request, including a "Request-URI"
[RFC2616] that should be interpreted as a /resource name/
defined in Section 3 (or an absolute HTTP/HTTPS URI containing
the /resource name/).
So, there are multiple places where it says the http request must be a GET.
As for your specific questions:
Should WebSocket server only handle GET requests?
Yes, a webSocket connection will always start with a GET request, not a POST or any other method.
If the upgrade request is not a GET request should the server handle it as a WebSocket upgrade request, should it pass it to be handled by the HTTP server or should it respond to it with a status code like 400 Bad Request ?
As described in the above reference portion of the specfication, the server should respond with a status code like 400 Bad Request.
Could this be a design decision where the server decides not to handle methods which are not GET requests?
Yes.
I'm developing an application which acts as an Http-Proxy for serving files from an external resource. It actually downloads the file from the external resource, checks for viruses and if the file is not infected, returns the file to the client.
My problem is, in case of the file is infected, what HTTP Status code my service should return? I suppose that any type of 4xx error codes is not appropriate for that situation because this class of code is intended for Client errors.
Is a 502 (Bad Gateway) error more appropriate?
Is there any kind of Standard that covers this situation?
I think you are right maestromarko : 502 Bad Gateway. Read the specifications here:
The 502 (Bad Gateway) status code indicates that the server, while
acting as a gateway or proxy, received an invalid response from an
inbound server it accessed while attempting to fulfill the request.
Your proxy is acting as a Gateway and he received what it conciders is invalid as there are virus in it.
It is not a 4xx class error, because whatever the client changes in the request, the result will still be an error.
See also this decision diagram
Http response codes are only meant to handle http specific conditions so I don't think there is a correct answer as such. But some possibilities...
204 - "The server successfully processed the request and is not returning any content"
403 - "The request was valid, but the server is refusing action"
https://en.m.wikipedia.org/wiki/List_of_HTTP_status_codes
What is optimal HTTP response Code when not reporting 200 (everything OK) but error in input?
Like, you submit some data to server, and it will response that your data is wrong
using 500 looks more like Server Issue
using 200 with warning/error response text is bad (allowing caching and everything is not OK)
using 204 and returning nothing, is maybe good (but well supported?)
using 404 is wrong if requested path (script) is available and in proper place
We had the same problem when making our API as well. We were looking for an HTTP status code equivalent to an InvalidArgumentException. After reading the source article below, we ended up using 422 Unprocessable Entity which states:
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415 (Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.
source: https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm
Codes starting with 4 (4xx) are meant for client errors. Maybe 400 (Bad Request) could be suitable to this case? Definition in http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html says:
"The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. "
409 Conflict could be an acceptable solution.
According to: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.
The doc continues with an example:
Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.
In my case, I would like to PUT a string, that must be unique, to a database via an API. Before adding it to the database, I am checking that it is not already in the database.
If it is, I will return "Error: The string is already in the database", 409.
I believe this is what the OP wanted: an error code suitable for when the data does not pass the server's criteria.
I recommend using 418 when client request something absurd that the server can't process. Like the server is a teapot but client is requesting coffee kind of stuff. Here is all the (400–499) client side error messages: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#client_error_responses
404 - Not Found - can be used for The URI requested is invalid or the resource requested such as a user, does not exists.