I am building a RESTful API. When the client uses an unsupported method such as POST on a resource that does not supports it, I am returning a 405 with the Allow header which lists the allowed methods:
Status Code: 405 Method Not Allowed
Allow: GET, HEAD, OPTIONS
Connection: keep-alive
Date: Mon, 08 Apr 2013 00:19:26 GMT
Transfer-Encoding: chunked
Is it allowed to have a body (to provide an error message) for 405 responses?
From the w3c's site, it is not apparent whether a body is allowed for 405 responses.
The HTTP/1.1 protocol spec states in the "message length" section:
Any response message which "MUST NOT" include a message-body (the 1xx, 204, and 304 responses and any response to a HEAD request) is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message.
A message body is optional for all 4xx-5xx codes as long as the HTTP method is not HEAD.
Related
Thread Name:Thread Group 1-1
Sample Start:2022-11-14 15:38:43 GMT
Load time:56
Connect Time:42
Latency:56
Size in bytes:1472
Sent bytes:2669
Headers size in bytes:1472
Body size in bytes:0
Sample Count:1
Error Count:1
Data type ("text"|"bin"|""):
Response code:401
Response message:Unauthorized
HTTPSampleResult fields:
ContentType:
DataEncoding: null
Response Header
Connection: keep-alive
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Accept-Language: en-GB,en;q=0.5
prefer: odata.include-annotations="*"
x-ms-sw-tenantid:
x-ms-user-agent:
clienthost: Browser
x-ms-client-session-id:
Accept: application/json
x-ms-source-id:
x-ms-sw-objectid:
x-ms-correlation-id:
content-type: application/json
x-ms-app-id:
I tried applying Cookie Manager and Authorization Manager but the code is failing everytime.
As per HTTP Status Code 401 description:
The HyperText Transfer Protocol (HTTP) 401 Unauthorized response status code indicates that the client request has not been completed because it lacks valid authentication credentials for the requested resource.
This status code is sent with an HTTP WWW-Authenticate response header that contains information on how the client can request for the resource again after prompting the user for authentication credentials.
So you either need to provide proper Authorization header via HTTP Header Manager or again properly configure the HTTP Authorization Manager to generate the header for you.
I have a Asp.Net WebApi method (POST) that works in one IIS server but when deployed to another IIS server (both the servers are IIS 8), if the request body is kept empty I get a error returned as below :
Request Rejected. The requested URL was rejected. Please consult with your administrator.
If I put any character in the request body - I get the expected result ! Any idea what I can check ? I believe some settings in the server - as the service is working in to former server - its only the later server that doesn't accept an Empty Request Body !
Unsuccessful request
Successful request/response when entered some garbage character in request body !
Update
The response header for the unsuccessful response:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Connection: close
Content-Length: 188
I am using Spring Boot to integrate to a third party which can provide gzipped responses and I want to log the size of the compressed response body vs the decompressed so we can audit for billing etc.
I'm using RestTemplate.exchange to make the GET request and the response is coming back correctly however I am unable to retrieve the Content-Length header in the response.
I know that the third party are sending it back because I can see it when I make the same request using Curl:
HTTP/1.1 200 OK
Date: Mon, 04 Feb 2019 15:40:10 GMT
Server: Apache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 558
Connection: close
Content-Type: application/json
This is my Java code making the request and logging the lengths:
final ResponseEntity<String> responseEntity = restTemplate.exchange(url, GET, entity, String.class);
final String body = responseEntity.getBody();
LOG.info("Payload sizes: compressed={}, uncompressed={}", responseEntity.getHeaders().getContentLength(), body.length());
For the request headers I am setting 'Accept-Encoding: gzip,deflate' as per the documentation for the third party. However when I get the response the call to getContentLength() just returns -1. I've done a lot of searching around on this and tried using a ClientHttpRequestInterceptor but no joy.
Anybody ever had the same issues?
Just in case anyone got same issue as I had, if you are using TestRestTemplate, it will not show Content-Encode when gzip, try use RestTemplate instead
I am currently debugging a surprising "Bad Request" response from an API.
Request:
POST /path HTTP/1.1
...
Response:
HTTP/1.1 421 Misdirected Request
Date: Fri, 30 Nov 2018 21:59:12 GMT
...
Via: https/1.1 subdomain.example.org (ApacheTrafficServer/7.1.4)
...
Per my research, HTTP status code 421 was only added with the http/2 specification. As you can see, my client is sending a HTTP1.1 request.
Does it make any sense to use it in the response to a HTTPS/1.1 request? What could it mean there?
Update: Further research indicates that this 421 response is triggered by an invalid CSRF token and Cookie value in the header, retrying the request with a verifiable valid combination returns the expected result with 200 OK. Unfortunately this doesn't really explain anything.
421 was added for HTTP/2 which allowed connection reuse. If a client reused a connection incorrectly (like Firefox used to) then the server should respond with this.
However that doesn’t mean it’s an HTTP/2 only status code. For example if a load balancer takes HTTP/2 requests in and passes them to back end servers over HTTP/1.1, then one of those backend servers can reject a request over HTTP/1.1 if it believes it was incorrectly sent that request. As you can see your request was sent via an Apache Traffic Server, so I suspect that is what happened here.
All,
Every HTTP Request I make to my test REST Service is sent with the method set to GET. Tomcat rejects with a 405 - Unsupported Method. Doesn't matter what I change it to (POST, PUT, etc) Jmeter always sends a GET.
I set up the simplest possible test case by creating a Threadgroup with an HTTP Request Sampler and a View Results Tree. I send a JSON body to the REST Services which just echos back the request along with an ID. Works great with Google's REST Client UI.
Here is the result from the View Results Tree:
Response code: 405
Response message: Method Not Allowed
Response headers:
HTTP/1.1 405 Method Not Allowed
Server: Apache-Coyote/1.1
Allow: POST
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 1045
Date: Fri, 18 Jul 2014 21:39:27 GMT
Here is the RequestMapping from my REST Service
#RequestMapping(method = RequestMethod.POST, consumes = "application/json", produces = "application/json")
Here are some screenshots from my results. I wonder why there are two URI's below the HTTP Request in the tree? Notice the POST request looks correct.
Since the right answer is not provided yet: It's the "Follow Redirects" Option that causes this behavoir under certain circumstances.
see http://www.sqaforums.com/showflat.php?Cat=0&Number=687068&Main=675937
Try to end the 'Path' value of HTTP Request with '/'. It has to remove the GET result in View Results Tree.
I had the same problem. I tried everything also I read this question and all answers before find the thing that worked for me.
Content-Type should be application/json. It can not be text/html.
Set that in HTTP Header Manager. I assume you have set authentication details correctly.
We need to have three things properly set.
Content type which will be application/json
set the endpoint correctly in the path ,which you can see in soup ui
Check the port number on which the api wil get run on [All this u can first check on soupui and then try running the same in jmeter