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.”
Related
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 am creating different HTTP Requests for a site and taking an access token as a variable from Regular Expression Extractor and using it in another HTTP Request.
The Thread group is working fine; i.e. no error in View Results Tree. But Response data is only coming for the Request with POST Method. Nothing is coming for the Request with GET Method and both requests are taking the access token properly.
In some cases you may get response code 200 ok and request still may fail. In case of your get request that seems to be happening.
Check following:
Headers being sent with get request. (Compare request being sent from JMeter and from real browser.)
Add response assertion to get request to be assure the correctness of the response. (Check what response you get for the request made from browser.)
Make sure you have added cookie manager in the test plan.
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
Which http response code best notifies a user that an api only ajax and post are accepted?
For example i have a controller that will only allow ajax requests and these must be post and not get.
So if an end user was to request using get or post using non ajax they should get a response to indicate this is not allowed.
Would either of these be the best response for this:
400
403
405
400 - Bad Request, 405 - Method not allowed
I think yours is 405, 403 is forbidden, regarding access permissions, not format or method. Bad Request could be a combination of forbidden parameters
HTTP doesn't have status code to distinguish between requests initiated by XmlHttpRequest (you call it AJAX) and requests made by any other HTTP client or directly by browser.
I guess that by non-ajax request you mean request that is made directly by putting an URL into browser (or by click on a link). It means that browser performs GET request.
HTTP allows you specify set of allowed HTTP methods for particular resource.
To fulfill your use-case you just need status code which allows you specify that just POST method is allowed.
405 - Method not allowed
The method specified in the Request-Line is not allowed for the
resource identified by the Request-URI. The response MUST include an
Allow header containing a list of valid methods for the requested
resource.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.6
Practically it means that your server will return 405 for GET,PUT,DELETE methods.