I have recorded a script and running it. But I'm receiving the following error.
HTTP Status 405 - Request method 'POST' not supported in jmeter
I'm not sure whether it is script issue or coding issue.
Our application is installed on HTTPS but security certificate not yet installed.
Could any one please help me out.
It could be one of below
The endpoint you are requesting is not supported for POST, It may support only GET, Please change the method in Jmeter to GET or the method your url supports
The endpoint may expect proper CSRF token. It might mismatch with one you recorded. So Please extract CSRF token from previous request's response and use it. You can do via RegEx Extractor in Jmeter.
JMeter does support POST method so it may be due to:
Endpoint you're using doesn't support POST method (it expects other method(s) like GET, PUT, DELETE, etc.)
You're sending not properly configured request.
The most common reason is missing relevant Content-Type header. You can use HTTP Header Manager in order to send the relevant Content-Type header which is usually application/json for REST or text/xml or similar for SOAP.
See Testing SOAP/REST Web Services Using JMeter article for more information on API testing using JMeter.
You can also consider the following approach:
Use specialized Web Services testing tool like SoapUI or RESTClient to fire a request
Either use aforementioned tool or 3rd-party sniffer like Wireshark to capture the request
Configure JMeter to send exactly the same request
Related
I am getting the below error when I am trying to hit a request having Method: PATCH
Using JMeter Version:-apache-jmeter-5.4.1
"java.net.ProtocolException: Invalid HTTP method: PATCH at
java.base/java.net.HttpURLConnection.setRequestMethod(HttpURLConnection.java:487)
at
java.base/sun.net.www.protocol.http.HttpURLConnection.setRequestMethod(HttpURLConnection.java:596)"
It will be helpful if I get expert assistance to resolve their issue.
Thanks
You need to change "Client Implementation" to HttpClient4 either at "Advanced" tab of the HTTP Request sampler or in the HTTP Request Defaults - this way the change will be applied to all HTTP Request samplers in the HTTP Request Defaults scope
There are diffrent HTTPSampler implementations the Java one uses HttpURLConnection here. As you can see in this bug ticket it does not support PATCH
In user.properties
HTTPSampler.implementation: HttpClient4
or in jmx using
<stringProp name="HTTPSampler.implementation">HttpClient4</stringProp>
I have a web service running in AWS (DomainA) and it is runnning fine. It is a REST service made in Java using JAX-WS and Jersey. I have a responsefilter on which adds access to all domains (Access-control-allow-origin *) and this should be working because if I remove it, I can not even get the web service to work locally.
I have bought a domain on one.com (DomainB) in which I redirect all requests to DomainA using .htaccess. Now, when I try to call some REST method on DomainB this works fine wherever I call it (if it is a GET method). If it is a POST method it also works for POSTMAN but in Chrome I get the infamous:
Failed to load "ServiceB". Redirect from "ServiceB" to "ServiceA" has "MyPage" been blocked by CORS policy: No Access-Control-Allow-Origin is present...
If I call DomainA directly I can see in my response headers that all domains are allowed and everything works fine.
Any ideas why CORS is not working when it is through my DomainB?
It's Chrome itself which 'enforces' CORS - the browser adds the Origin request header (and makes a CORS preflight OPTIONS request if necessary) and checks for the various CORS response headers such as Access-Control-Allow-Origin.
Browsers only do this for fetch/XmlHTTPRequest (the latter is simply a wrapper for the former). So if you run your web service directly (outside of an actual browser), no CORS processing will occur on the client-side.
It's only when you run it within a browser that you'll see CORS issues.
When sending a request to an OAuth2 Token Endpoint, the RFC says, the response has to be in JSON format. When using Spring Security, strange things happen however. To be sure, the fault isn't in my code, I used the demo app Sparklr2 to test the following. The problem is, that depending on the user agent I use, the result is different.
I access the url http://localhost:8084/sparklr2/oauth/token
If I use curl, Advanced REST Client, telnet or similar, the result is just as expected:
{"error":"unauthorized","error_description":"Full authentication is required to access this resource"}
If I however user Firefox or Chrome I get an answer in XML format:
<oauth><error_description>Full authentication is required to access this resource</error_description><error>unauthorized</error></oauth>
Why does this strange behaviour happen?
Spring probably honors the Accept header. Browsers usually send application/xml as an accepted format. REST clients usually include application/json. CURL does not send anything (unless you define it) and Spring probably prefers the JSON in such case.
As for the format itself I have found this - https://datatracker.ietf.org/doc/html/draft-richer-oauth-xml-01#section-4.1 .
I wrote a context.io 2.0 java client for : accounts,discovery, threads and messages operations to be used in my project (based on the available ContextIO Java client).
My code is at : https://github.com/dileepajayakody/isis-reputationbox/blob/master/reputationbox/dom/src/main/java/at/tomtasche/contextio/ContextIO_V20.java
While testing it, when I invoke the accounts request: https://api.context.io/2.0/accounts and discovery requests (eg: https://api.context.io/2.0/discovery?email=testemail#gmail.com&source_type=IMAP, I successfully get the desired response with a HTTP 200
However when I invoke the messages, threads, contacts requests by adding the account_id parameter in the request URL (eg : https://api.context.io/2.0/accounts/1234ff425ad/messages) I get an empty JSON array with a HTTP 403 Forbidden response.
When I try out the same request in the contextio developer console, I get the response without a problem.
I don't think it's something wrong with the way I sign the oauth request since it's the same way I sign for accounts and discovery requests for which I get the contextIO response properly.
Any help in resolving this error is much appreciated.
Thanks,
Dileepa
I don't think the issue is related to oauth request signing, since we normally return 401 or 404 messages for errors there.
The fact there's no body content with the 403 response leads me to believe your api_key does not own the account specified. If it did own it then we would include a json array with type, code, value parameters to help debug the issue. If you have two developer accounts then you may just be using the wrong one for this test.
I hope this helps. If not, please feel free to contact us at support#context.io.
Thanks!
Dan
I'm a little unfamiliar both with the Servlet API and Apache Http Components.
I need to handle an incoming POST request with unknown data (although probably the result of a form submission) using HttpServlet.doPost() which I've implemented, and request the same posted information from another URL, effectively acting as a relay for the HTTP POST. I then need to convert the response to a String (it will be text/html) and process it further before returning it to the web browser that requested it from me.
Due to my unfamiliarity with these libraries, its not clear to me how to handle issues like the content-type of the posted data, and also avoiding any problems due to neglecting to release resources.
Can anyone provide any pointers on this?
You should start by having a look at HttpClient class from apache API.
It will handle both get and posts as needed and later you could feel its request with the data you receive in your own servlet.