i have a working project with jmeter 3.1 using soap request sampler :
Project Jmeter with version 3.1
Http header manager congig
i tried to figure out the same project with jmeter version 5 using http request like this :
Project jmeter version5
but i receive always those 2 error :
Error received
can you help on this please ?
I don't know what is in your HTTP Header Manager, but the system under test complains that you're not providing correct Content-Type header which must be text/xml
I believe if you add this header at least this issue will go away.
Going forward you can just record your test from JMeter 3.x in JMeter 5.x and it will generate relevant HTTP Request samplers and HTTP Header Managers.
More information: Testing REST\SOAP Web services
Related
I'm testing TMS WEB Core 2 and DMVC 3.2.2 (latest) on Delphi 11.2 by me test machine locally.
I've created a simple DMVC server with all default's setup through the wizard nothing fancy except added the CORS option.
I've created a TMS Web core project with all default's setup as well with a WebHttpRequest and WebMemo components.
I ran the DMVC server and can get the result beautify on the browser.
I ran the TMS Web core project to send a request to the server using
WebHttpRequest which is like this:
WebHttpRequest1.URL := 'http://localhost:8080/api/test';
WebHttpRequest1.Execute(
procedure(AResponse: string; AReq: TJSXMLHttpRequest)
begin
WebMemo1.Lines.Add(AResponse);
end
);
However I got this error:
ERROR
HTTP request error #http://localhost:8080/api/test | fMessage::HTTP request error #http://localhost:8080/api/test fHelpContext::0
at http://localhost:8000/Project1/Project1.js [263:50]
and the browser developer console shows:
Access to XMLHttpRequest at 'localhost:8080/api/test' from origin 'localhost:8000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header has a value 'localhost:8080' that is not equal to the supplied origin.
I want to send a request from the client to the server and get the respond in the WebMemo..
I've checked online to find that it's a backend-end problem, and some say its related to CORS, So How can I enable the CORS on server side using DMVC?
Your configuration prevents the client from connecting.
Both the server name and the port must match the CORS rule. To fix this, change the CORS header to a matching value.
This could be
Access-Control-Allow-Origin: http://localhost
or
Access-Control-Allow-Origin: http://localhost:8000
Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
I was doing a automation testing on my web application with SOAPUI, I have found a bug which is http method fuzzing basically it means "HTTP Method Fuzzing
An HTTP Method Fuzzing Scan attempts to use other HTTP verbs (methods) than those defined in an API. For instance, if you have defined GET and POST, it will send requests using the DELETE and PUT verbs, expecting an appropriate HTTP error response and reporting alerts if it doesn't receive it.
Sometimes, unexpected HTTP verbs can overwrite data on a server or get data that shouldn't be revealed to clients."
Can anyone knows how I can solve this issue or how I block the HTTP request other than GET or POST which may remove this bug.
I am using Node.js and express for my web application.
Please check the images:
Image 1
Image 2
How we can control over the number of header going with the HTTP request? e.g.; If I don't want to send the "Cache-Control" header,how to control it?
I am using HttpClient for sending a JSON formatted request.
Using 4.5.1 version of org.apache.httpcomponents and 3.1 version of commons-httpclient in maven dependencies.
I have got url for svc file. For example https://Myservicelocation/UserService.svc.
Now i tried to create asp.net web application in visual studio and added this url using "Add service reference". When i put this url and then click go i get error
The request failed with HTTP status 400: Bad Request.
Metadata contains a reference that cannot be resolved: 'https://Myservicelocation/UserService.svc'.
Content Type application/soap+xml; charset=utf-8 was not supported by service https://Myservicelocation/UserService.svc. The client and service bindings may be mismatched.
The remote server returned an error: (415) Cannot process the message because the content type 'application/soap+xml; charset=utf-8' was not the expected type 'text/xml; charset=utf-8'..
If the service is defined in the current solution, try building the solution and adding the service reference again.
How can i resolve this?
Google says..
Probably a mismatch in the client/server bindings, where the message version in the service uses SOAP 1.1 (which expects application/soap+xml) and the version in the client uses SOAP 1.2 (which sends text/xml). WSHttpBinding uses SOAP 1.2, BasicHttpBinding uses SOAP 1.1.
Align your bindings accordingly...
I had the same problem.
Try https://Myservicelocation/UserService.svc?wsdl link.
I have to use a 3rd party web service implemented in .NET 2.0 (on IIS, of course).
I have to make a java client. I am using wsdl2java to generate the SOAP stub.
As the original Apache Axis project now appears unmaintained, and I was having some problems parsing some responses from the service, I converted the client to use the latest (1.5) version of Axis2. Now, the .NET service won't even recognize my requests.
I managed to get the "chunking" turned off (where "stub" is a variable of type MumbleStub generated by wsdl2java, and I am showing what are several lines of code as one horrific line here):
stub._getServiceClient().getOptions().setProperty( HTTPConstants.CHUNKED, Boolean.FALSE);
.. so at least the service recognizes my request AS a request, albeit a bad one: "HTTP/1.1 400 Bad Request" is the response now (as opposed to an "intro / summary" page offering me a link to the WSDL).
I noticed that the Axis ("1") request had a different Content-TYpe header (text/xml, vs application/soap-xml), and I am wondering how to change this request header, if that is in fact the problem.
Alternately, has anybody else had this problem? Is the problem really the (undisplayable here, as it looks like "element injection" to the blog engine) ... xml version-"1.0" ... "XML meta intro tag" that Axis2 added to the beginning of the request?
WS-Deathstar, indeed.
As you mention the different content-type header I guess your client tries to send SOAP 1.2 requests and the 3rd party app only understands SOAP 1.1
Try changing the used soap version as AFAIK AXIS2 uses SOAP 1.2 by default
stub._getServiceClient().getOptions().setSoapVersionURI(org.apache.axiom.soap.SOAP11Constants.SOAP_ENVELOPE_NAMESPACE_URI);