I am facing a very strange issue in my project. It is related to rest API call using spring reactive webclient bulider. It is working fine on local and prod as well but abnormally giving below error after 3 or 4 request to same endpoint.
"org.springframework.web.server.MethodNotAllowedException: 405 METHOD_NOT_ALLOWED "Request method 'T' not supported"
This is valid exception as method going to "T" for Get method and "ST" for Post method .I am not able to understand why two starting charcter truncating from method name
Please help me resolve this error.
OP and I must have been the only ones to have ever experienced this and honestly I don't know the root cause but this was my situation and the fix.
For me, I was running 2 services in a docker. One service would make requests to the other. The 1st request always succeeds but the subsequent one always fails. After some time, a new request succeeds again.
I speculated that it must have to do with a persistent connection. I am using OkHttpClient library (3.14.9) to make the request. The service receiving the request was running spring webflux but I don't think the service was the issue. I could make repeated successful requests to it using curl from inside the 1st service's container.
OkHttpClient uses keep-alive connections by default. You can specify for a single request that you don't want to keep connection alive by setting the Connection header to close. Once I did that, all requests were working again.
For whatever reason, the re-use of the keep-alive connections was not sending over over and entire request. It was always truncating the first 2 characters of the method that is why Request method 'T' not supported. Perhaps the 1st request didn't end correctly and eats up the 2nd request's first 2 characters. I don't know the root cause. Probably a bug with OkHttpClient
Related
I have run into a fairly annoying problem with Quarkus, that I cannot figure out how to solve.
I am using quarkus 2.4.1.Final. I am using the quarkus-resteasy-reactive-jackson module to create a REST service.
But when I send the service a post body with a bad format the client simply gets an empty HTTP 400 response back, and nothing is printed in the log on the server side. In this particular case I forgot to add the offset to an OffsetDateTime, so adding "+01:00" makes the service return correctly. Using micrometer metrics, I can see that the endpoint is being hit correctly both when the request is correct and when it isn't.
Hiding an exception from the developer is very close to heresy for me, as I would like to be able to see what the server fails with. I understand that we don't want the stack trace on the client side, but in this case the exception is missing from the server log.
Can anyone help me to convince Quarkus to not swallow my exceptions?
I have read and tried the solutions shared in the previous posts for this error but nothing helped me to fix this. Kindly help.
I am making a HTTPS API call. A very simple call which accepts a 2 KB JSON message via POST method and sends a one word acknowledgement. It works perfectly fine in Postman tool. In JMeter, no. of threads (users) is kept as 25. It works perfectly fine one time with all 25 success response and at times getting few failure response as
Response code: Non HTTP response code: java.net.SocketException
Response message: Non HTTP response message: Unexpected end of file from server
No consistency at all. I have also tried with both enabling and disabling "use keepalive" checkbox. Both giving me all success one time ; few/all failure at another time with the above error. Please help. Thank you.
Below are the JMeter settings:
HTTP Header Manager : Content-Type - application/json
HTTPRequest sampler : protocol - HTTPS
Server Name or IP : project server name
Method : POST
PATH : The required path with https authentication details passed as parameters
IMPLEMENTATION : Set to JAVA (HTTPCLIENT4 was giving me “443 failed to respond” error)
Add header
Connection Keep-Alive
Both errors (Java implementation and Apache HTTPClient4 implementation), are essentially saying the same thing: The server closed the connection, without providing any response. I think there could be the following reasons:
Authentication problem. If server side checks authentication before processing a request (e.g. using Spring), it may be rejecting your request, it may be not bothering with any response if authentication is not considered correct.
Request Issue. Some less noticeable properties of the request you send via Jmeter are different from what you send in Postman. It could be some minor thing with formatting, or some headers server expects. Some of such inconsistencies can also cause Load Balancer (if you use one) to reject request before it's delivered to the server.
Certificate issues. Since you are using HTTPS, you need to make sure your certificate is setup correctly on JMeter side.
So I suggest:
Review server logs and see if your request makes it to the server. If yes, you might be able to see how it was rejected. If not, you need to trace back and see who rejected it (LB, authentication, etc)
Compare headers and body sent by JMeter vs Postman line to line (use TCPDump for example to obtain it).
I am facing below error in respose,
<faultcode xmlns:ns1="http://xml.apache.org/axis/">ns1:Client.NoSOAPAction</faultcode>
<faultstring>no SOAPAction header!</faultstring>
i am trying to fixing in pipeline ,
selected pass all headers through pipeline but didn’t helpedenter image description here
Do you really need a SoapAction?
One of the options available in a proxy is to decide which operation a SOAP message is, by inspecting the message body.
If someone sends a message (perhaps through a biz ref) and doesn't include a SOAP action header, a proxy will still recover if it uses this method.
In this scenario there are two HTTP microservices:
The public service that provides the client with data
The internal microservice that authenticates calls to the public service
Service 1 makes a call to Service 2 to ask it to authenticate the token provided to it by the client.
The agreement ("contract") is that Service 2 should reply with 200 OK and JSON content about the authenticated user.
In Service 1, if it receives the response 200 OK, is it worth going any further to validate the response further?
For example, the JSON body of the response is parsed into an object. Is there value in checking if that object was correctly instantiated instead of being set to null? Or alternatively should that be left to integration tests?
Strictly, a 200 only means that the request was successfully processed. This is regardless of the actual outcome of the call from a business perspective.
You are in effect relying on a convention of "we will throw an exception or otherwise fail the call if the user is not authenticated", to authenticate users.
Depending on the convention, you could conceivably have a scenario where a user was unauthenticated but the call was still successfully processed.
From this perspective, it may be worth having the service2 return a response which could then be interrogated to close this circle.
Alternatively, you could have the client call the authentication service directly, retrieve a token, and then present this token with any other request. This would mean that service1 is no longer responsible for having to know that a caller is authenticated.
The question is whether or not to then test in Service 1 each time the
response is received
Sorry, I would appear to have misunderstood the spirit of the question somewhat.
I am slightly confused - are you asking that, if the system under test is service1 then should any response from service2 also be part of that test?
I would say you would have to have some test which could prove that the sercvice2 response interrogation logic is correct, but this could be done at the unit test level. I don't think you'd need to do this for tests running against a deployed instance of the service, which is by nature more about the service behaviour at the boundary rather than internally.
Well your approach is not that bad!
Some of the HTTP status codes are reserved for cases of malformed requests etc. but in your case, you ask Service2 to return information for a token! If that token exists, you specified correctly, that Service2 has to return 200 OK. Now you just need to specify what happens if the token is not valid anymore or if it does not exists (or treat both cases the same...). If you specify, that Service2 has to return 404 Not found if it does not know the token or that the token expired, there (in most cases) is no need for Service1 to go any further! Parsing the status code is cheap in almost any language/environment, but forcing the deserialization of the content in both success and error cases is in comparison very expensive. Authentication needs to be fast - so I'd go for the status code here!
The key is, that this behavior has to be specified somewhere! (We went for swagger definitions!)
For DELETE APIs, if we hit the API with invalid data, the API responds with proper error message. If we use the same HTTP connection object to hit another API, the request fails.
This issue is not seen for Create or Update APIs. Also if the Delete request is sent with valid data, then using the same HTTP connection object for next request works fine.
Please note that this behavior has implications for connection pooling in client applications, and we were just wondering if its known issue and if there is any available workaround.