Provider side matching is not working if I add any thing or rename or remove any field in request body of provider which is not same as contract then its not failing.
Eg inside contract file request body contain name field and the same field if I remove or rename in request body of provider (not in response) only in request then pact is not validating that.
I want to confirm at provider side will the matching work on request body?
I can see matching rule for request body in pact file but its seems like not functioning.
Adding new fields into a provider response that is not required by a Pact contract is simply ignored.
Why is this the case? Pact follows Postel's Law. Unexpected elements in a response should not cause issues for a consumer. Other consumers may have different but overlapping needs, so failing a provider build on these grounds is problematic.
From our docs, what this translates to:
Be conservative in what you send - when the mock server in the consumer project compares the actual request with the expected request, the actual request body is not allowed to contain fields that are not defined in the expected request body. We don't want the situation where our real consumer is "leaking" data that we don't know about.
Be liberal in what you accept - when verifying a pact in the provider project, the response body and headers may contain fields that were not defined in the expectations, on the assumption that any extra field will be ignored by your consumer. This allows a provider to evolve without breaking existing consumers (unlike the bad old WSDL days).
To your second point:
I want to confirm at provider side will the matching work on request body?
It sounds like it is working. It's correctly identifying breaking changes if you change the datatype, or have an unexpected response code.
If you rename a field that is required by a consumer, then that sounds like a bug (a fatal one in terms of Pact features, so I'm skeptical).
I have written regex for response but the .json files are are creating with some wierd values like ABSGDKJEUDSGASH,
Can some help me in these
Response:
'agent': value(consumer((anyNonBlankString())), producer("abcd"))
Created Stubs
\"agent\":\"CVCHFTMETQSEOLOQENTY\":
Can spring cloud contract support response dynamically as it supports request??
consumer() is related to stubbing, producer() is related to the generated test. The matching in the request part is to make sure that the incoming HTTP request on your WireMock server matches the criteria that you have specified. Now everything that you write in the response side is what WireMock will return if your HTTP request matches those criteria.
If you need to return a fixed value, use consumer('my agent').
If it doesn't matter what you receive as a response, you can use eg. consumer(anyNonBlankString()).
If you want to return the same value as what you received from the client you can do something like consumer(fromRequest().header('agent')).
Hope that helps! :)
I have an application which uses Apache Camel to build an API. It basically uses blueprint.xml to define routes and processing is done by a bean(please note its not any processor bean. Just a plain Java bean). It uses Jersey client to invoke the backend system Rest API.
My requirement is to get the http headers in the code to be able to send them to our custom logging system.
a) I tried #httpHeaders annotation but this does not inject the headers on my code.
b) Since its not using any BeanProcessor i dont have an Exchange object from where i can get the header values.
Please help with a way to get header values on the code.
Add the request context to your class
#Context
private HttpServletRequest request;
and get the headers in your endpoint using request.getHeader
Returns the value of the specified request header as a String.
I have proprietary http based API to test from JMeter. Unfortunately some of the endpoints of the API are expecting http DELETE method with a request body (I know its questionable API design to use DELETE with request body, but I have no ability to change that API and need to test it).
How can I test it from JMeter? It seems that standard HttpRequest sampler silently ignores my body payload without any warnings. (When I try it in POSTMAN its sending a request body for DELETE method)
I did find an old JMeter plugin called HTTP Raw Request that somewhat helps but still doesn't auto-calculate "Content-Length:" http header for my body payload...so I have to do it manually for every test case - which is a pain for dynamically generated data payloads.
So my question still remains: How can I test HTTP DELETE with request body from JMeter?
Here is the screenshot:
NOTE1: Starting from jMeter ver. 3.1 (see bugzilla #60358) it was fixed for Http GET request to be able to send body in the request...but DELETE was not added.
NOTE2: See bugzilla #61443 for the DELETE request with body.
NOTE3: I'm using client implementation called "Java".
As per reference docs:
http://jmeter.apache.org/usermanual/component_reference.html#HTTP_Request
There are 2 implementations for http request sampler. The non default one called "Java" has this issue with not passing DELETE request body.
Luckily the default implementation called "HttpClient4" that correctly passes request payload for DELETE operation as per JMeter data entry screen.
To change implementations for http request sampler you have to go to "advanced" tab of the HTTP Request Sampler and select client implementation "HttpClient4" instead of "Java". Here is the screenshot:
After that when executed it correctly sends request payload for DELETE operation. Here is the screenshot:
Is it allowable to pass parameters to a web page through the URL (after the question mark) when using the POST method? I know that it works (most of the time, anyways) because my company's webapp does it often, but I don't know if it's actually supported in the standard or if I can rely on this behavior. I'm considering implementing a SOAP request handler that uses a parameter after the question mark to indicate that it is a SOAP request and not a normal HTTP request. The reason for this that the webapp is an IIS extension, so everything is accessed via the same URL (ex: example.com/myisapi.dll?command), so to get the SOAP request to be processed, I need to specify that "command" parameter. There would be one generic command for SOAP, not a specific command for each SOAP action -- those would be specified in the SOAP request itself.
Basically, I'm trying to integrate the Apache Axis2/C library into my webapp by letting the webapp handle the HTTP request and then pass off the incoming SOAP XML to Axis2 for handling if it's a SOAP request. Intuitively, I can't see any reason why this wouldn't work, since the URL you're posting to is just an arbitrary URL, as far as all the various components are concerned... it's the server that gives special meaning to the parts after the question mark.
Thanks for any help/insight you can provide.
Lets start with the simple stuff. HTTP GET request variables come from the URI. The URI is a requested resource, and so any webserver should (and apache does) have the entire URI stored in some variable available to the modules or appserver components running within the webserver.
An http POST which is different from an http GET is a separate logical call to the webserver, but it still defines a URI that should process the post. A good webserver (apache being one) will again make the URI available to whatever module or appserver is running within it, then will additionally make available the variables which were sent in the POST headers.
At the point where your application takes control from apache during a POST you should have access to both the GET and POST variables and be able to do whatever control logic you wish, including replying with a SOAP protocol instead of HTML.
If you are asking whether it is possible to send parameters via both GET and POST in a single HTTP request, then the answer is "YES". This is standard functionality that can be used reliably AFAIK.
One such example is sending authentication credentials in two pieces, one over GET and the other through POST so that any attempt to hijack a session would require hijacking both the GET and POST variables.
So in your case, you can use POST to contain the actual SOAP request but test for whether it is a SOAP request based on the parameter passed in GET (or in other words through the URL).
I believe that no standard actually defines the concept of "HTTP parameters" or "request variables". RFC 1738 defines that an URL may have a "search part", which is the substring after the question mark. HTML specifies in the form submission protocol how a browser processing a FORM element should submit it. In either case, how the server-side processes both the search part and the HTTP body is entirely up to the server - discarding both would be conforming to these two specs (but fairly useless).
In order to determine whether you can post a search part to a specific service, you need to study this service's protocol specification. If the service is practically defined by means of a HTML form, then you cannot use a mix - you can't even use POST if the FORM specifies GET (and vice versa). If you post to a web service, you need to look at the web service's WSDL - which will typically mandate POST; with all data in a SOAP message. Etc.
Specific web frameworks may have the notion of "request variables" - whether they will draw these variables both from a search part and a request body, you need to find out in the product documentation.
I deployed a web application with 3 (a mobile network operator) in the UK. It originally used POST parameters, but the 3 gateway stripped them (and X-headers as well!). So beware...
allowable? sure, it's doable, but i'm leaning towards the spec suggesting dual methods isn't necessarily supposed to happen, or be supported. RFC2616 defines HTTP/1.1, and i would argue suggests only one method per request. if you think about your typical HTTP transaction from the client side, you can see the limitation as well:
$ telnet localhost 80
POST /page.html?id=5 HTTP/1.1
host: localhost
as you can see, you can only use one method (POST/GET, etc...), however due to the nature of how various languages operate, they may pick up the query string, and assign it to the GET variable. ultimately though, this is a POST request, and not a GET.
so basically, yes this functionality exists, is it intended? i would say no.