Checking the headers HttpRequestExecutingMessageHandler i notice a common header,
accept-encoding, gzip which throws an Exception on response during the convertion phase, i.e. the message could not be converted throwing an error on response. Which is my guess related to the undelaying HttpClient used.
Is there any reason to put this header on the RestTemplate by default? Removing the header with the header filter the Rest request ran normally.
Also i tried to use a RestTemplate - but the header remains there, so just the header filter worked.
But when testing internally (using the HTTP Rest to connect distinct Integration instances) things worked normally, i.e. the header message is handled normally(and i don't know the reason since the out. problem occurred with outbound RestServers.
The flow as example is bellow.
Regards,
**
IntegrationFlows.from("theRequestChannel")
.transform(Transformers.fromJson(MyClass.class))
.enrichHeaders(m -> m.header("app_id", "appid"))
.enrichHeaders(m -> m.header("app_key", "app_key"))
.headerFilter("accept-encoding")
.handle(myHandler())
.get();
**
Fully unclear what you are asking. There is no an accept-encoding auto header in Spring Integration. I may assume that you have an HTTP Inbound Channel Adapter and this header is sent by the outside client to you application.
If the REST Service you need to call really doesn't like that headers, that us really a good choice to filter such a header before performing a request. Such a header is not configured on the RestTemplate, since you don't exclude it from there, but filter before reaching that RestTemplate.
Another option you can consider is a DefaultHttpHeaderMapper with its setOutboundHeaderNames() to configure a set of header patterns to transfer from the message to HTTP request. Of course, excluding the mentioned accept-encoding.
Related
I am trying to get an access token via RestTemplate.postForEntity().
myRestTemplate.postForEntity(authBaseUrl, request, Object.class);
I have a specific class for it, but let's use now a simple Object as type. It contains an access_token field.
It works, because I can get response, but the length if the access tokens (which is a string)
is 1196 character long. And I can get the same length in Postman too.
But if I use the intelliJ built-in REST client, the length is 1199.
Only the token from the intelliJ rest client works (So the longer).
Because I always get a new access token, it is impossible to get the same token twice.
How can I debug it?
What could be the problem?
Is the code that generates the response available to you? if so in your response add a header content-length so you can see what the server sent and what you received. Also, debug the server side and see what is being generated. In addition take another 3d party Http client and test it with this client see if you see a difference. The Http clients that you can try are Apache Http client, OK Http client, or my favorite - a very simplistic client written by me as part of my own Open Source MgntUtils library. Here is the Javadoc for my http client Here is a link to a similar question where you can get the references for any of above mentioned Http clients: How to check the status of POST endpoint/url in java
TL;DR:
Does stubby4j request proxying functionality support the setting of additional query params with the request which is being proxied?
Details:
I am using stubby4j HTTP stub server, the latest version (i.e.: v7.3.3) to proxy requests to another real live service when my request did not match any of the configured stubs.
I am interested to know if it is possible to pass in additional query params to the live service with the request which is being proxied?
In the official docs of the stubby4j request proxying behavior (https://stubby4j.com/docs/request_proxying.html) there is nothing mentioned about it and from what I see in my own testing, I do not think this is supported. But, I still wanted to ask on SO to check if I am simply doing something wrong.
You are correct, the the setting of additional query params on the request being proxied is not supported currently.
As per the aforementioned docs, the additive strategy only supports the setting of additional HTTP headers, which are specified in the headers property on the proxy-config object in your YAML.
But, it is pretty straightforward to add the addition of query params behavior. Feel free to raise a feature request at https://github.com/azagniotov/stubby4j/issues/new/choose
Im using Jmeter to write some load tests on an API secured by oAuth.
I want to be able to reuse the header manager once the bearer token has been produced from the access token call.
However when I try to move the header manager out side of the http request the call is no longer authorised. I think its because it can no longer get the bearer token.
For Post Request, when i put the header manager outside it no longer works, it only works when I put it under the request as I have done for User get request, Delete request and Put request.
How do I make the header manager reusable and therefore only manage one header manager?
Thank you.
{"fault":{"faultstring":"Invalid access token","detail":{"errorcode":"oauth.v2.InvalidAccessToken"}}}
My expectation is that this is due to clash with the HTTP Authorization Manager
Both are Configuration Elements and both obey JMeter Scoping rules
When you move HTTP Header Manager outside the HTTP Request sampler it might be the case that Authorization Header comes from the HTTP Authorization Manager
You can check which exact header value is being sent using Request -> Request Headers tab of the View Results Tree listener
Given you manually create Authorization header for your request I believe if you disable or delete the HTTP Authorization Manager your test should start working as expected as you basically don't need it.
I have a WebSocket server written which only handles upgrade requests which are GET requests. If a POST or any other kind of request with the required headers comes it is handled by a HTTP server.
In the specification it is not stated explicitly that the WebSocket upgrade request should be a GET request.
If the upgrade request is not a GET request should the server handle it as a WebSocket upgrade request, should it pass it to be handled by the HTTP server or should it respond to it with a status code like 400 Bad Request ?
Could this be a design decision where the server decides not to handle methods which are not GET requests?
From section 4.1 (Client Requirements) of the webSocket specification, it says this:
The method of the request MUST be GET, and the HTTP version MUST
be at least 1.1
And, then later in section 4.2.1 (Reading the Client's Opening Handshake) of the webSocket specification, it says this:
The client's opening handshake consists of the following parts. If
the server, while reading the handshake, finds that the client did
not send a handshake that matches the description below (note that as
per [RFC2616], the order of the header fields is not important),
including but not limited to any violations of the ABNF grammar
specified for the components of the handshake, the server MUST stop
processing the client's handshake and return an HTTP response with an
appropriate error code (such as 400 Bad Request).
An HTTP/1.1 or higher GET request, including a "Request-URI"
[RFC2616] that should be interpreted as a /resource name/
defined in Section 3 (or an absolute HTTP/HTTPS URI containing
the /resource name/).
So, there are multiple places where it says the http request must be a GET.
As for your specific questions:
Should WebSocket server only handle GET requests?
Yes, a webSocket connection will always start with a GET request, not a POST or any other method.
If the upgrade request is not a GET request should the server handle it as a WebSocket upgrade request, should it pass it to be handled by the HTTP server or should it respond to it with a status code like 400 Bad Request ?
As described in the above reference portion of the specfication, the server should respond with a status code like 400 Bad Request.
Could this be a design decision where the server decides not to handle methods which are not GET requests?
Yes.
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.