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.
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 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).
I have a server in which the client can register itself as a device (like a mobile device). For the registration, the device must be associated with another resource (say an user) which is already registered on the server. To do that, the client sends a Http Post request to the server, with two params, its own ID and the associated resource ID.
I need to choose an Http Status code to return when the client ask the server to do some procedure and one of the resources indicated in the parameters are not found.
I suggested 404, but my professor said that 404 is used the resource associated to the URI is not found, not when you submit a well-formed request with bad parameters.
What is the most suitable http status and why would you choose?
In my opinion, it fits to:
400 - Bad Request
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
OR
403 - Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.
Ref: fc2616
I would use 403 'Forbidden' - meaning, you are forbidden from accessing the page with the request you have sent
In Is HTTP 303 acceptable for other HTTP methods? we established that HTTP 303 can be used for other HTTP methods.
The Post/Redirect/Get pattern requires the server to carry out an operation before returning HTTP 303. Is the same true for HTTP PUT and DELETE for this and other types of redirects? Is the server required to carry out the operation before redirection? Or can it assume that the client will repeat the request on the canonical URL as necessary?
This becomes even more interesting when you consider the fact that redirection is often used for load-balancing.
Quoting RESTful Web Services page 378:
303 ("See Other")
The request has been processed, but instead of the server sending a response document,
it’s sending the client the URI of a response document. This may be the URI to a static
status message, or the URI to some more interesting resource.
A few pages later...
307 (“Temporary Redirect”)
The request has not been processed, because the requested resource is not home: it’s
located at some other URI. The client should resubmit the request to another URI.
For GET requests, where the only thing being requested is that the server send a representation, this status code is identical to 303 (“See Other”). A typical case where 307 is a good response to a GET is when the server wants to send a client to a mirror site. But for POST, PUT, and DELETE requests, where the server is expected to take some
action in response to the request, this status code is significantly different from 303.
A 303 in response to a POST, PUT, or DELETE means that the operation has succeeded
but that the response entity-body is not being sent along with this request. If the client
wants the response entity-body, it needs to make a GET request to another URI.
A 307 in response to a POST, PUT, or DELETE means that the server has not even tried
to perform the operation. The client needs to resubmit the entire request to the URI in
the Location header.
An analogy may help. You go to a pharmacy with a prescription to be filled. A 303 is
the pharmacist saying “We’ve filled your prescription. Go to the next window to pick
up your medicine.” A 307 is the pharmacist saying “We can’t fill that prescription. Go
to the pharmacy next door.”