I just started working with HandleHttpprocessor in Apache Ni-Fi ,trying to figure out if I need to configure anything in HandleHttpprocessor to support Access-Control-Allow-Origin issue.
HandleHttpRequest processor can only accept a request and it does not send any response to the client. Therefore you need to combine it with HandleHttpResponse processor in order to send the response back to the client.
You can set custom headers in HandleHttpResponse processor by adding custom properties to it. To do that you can add a dynamic property by clicking the 'plus' sign, then enter its name which will be the name of the custom HTTP header.
Ex: Access-Control-Allow-Origin: *
Related
My team planned to do API Performance Testing using JMeter 5.0 for my client. My client developed the API in Kubernetes. Just wondering, they gave info such as URI, HTTP Method and Content-Type only. We never have experience using URI. Are these info sufficient to do load test in JMeter? And where do I fill in these info? Is it in Config Element: HTTP Header Manager?
Because usually I only do my enablement using sample website which already provide the URL.
Do I need to ask them to provide the specific URL for this? Or URL can be extracted from URI?
Thanks.
Normally you should put:
Protocol, server name or IP and Port Number into HTTP Request Defaults, this way you will have a single configuration element having these details and in case of change you will need to introduce the change at one place only and won't have to revisit each and every HTTP Request sampler
Individual requests are defined using individual HTTP Request samplers where you need to provide URL Path and request body (if any)
Content-Type and other Headers can be provided via HTTP Header Manager, the same Scoping Rules as for HTTP Request Defaults apply, for example if you want to send application/json for all the requests just add HTTP Header Manager on the top of your Test Plan and it will add the header to all HTTP Request samplers which are at the same level as the HTTP Header Manager or lower.
I have a POST method exposed though an API in AWS API Gateway. It would process a certain JSON. But there is a weird requirement: I am supposed to accept anything and return always a 200 status code (as long as the service is available and working of course).
So if I receive a call with Content-Type: image/jpeg, application/xml or what/ever, I must be able to map the request to my Lambda function.
I have achieved to map any request to a custom type using the VTL (Velocity Template Language), the issue is that I must specify every single Content/Type I want to support in the Integration Request.
I would like to define a fallback mapping template for every Content-Type that is not among those that I have already defined. It is not allowed to specify "*/*" as Content-Type.
I can not use When no template matches the request Content-Type header option as passthrough because b y default the lambda function tries to deserialize the body from a JSON format.
Any ideas?
I think you should enable the When no template matches the request Content-Type header option. As documented your Lambda will get an API Gateway event. This event has a headers field that, on a POST should contain a content-type field. If your code understands the content-type then handle it. If not, return a response that has the correct status code and whatever is appropriate. This is not on the API gateway side but rather on the Lambda side.
See this blog for some additional ideas.
I have a NiFi flow which needs to post the data to some other server, before posting it needs to fetch a value from my internal server or Nifi Distributed cache.
And add that Value in to Http header before posting the data, also update when gets particular error code 401.
Below is the flow I am trying, all green processor I could do but stuck at getting the value and adding in invoke http header . What are other process I can make us to achieve this .
https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.9.0/org.apache.nifi.processors.standard.InvokeHTTP/
according to documentation on http code 401 InvikeHTTP routes file to No Retry relation.
also flow file should contain some response attributes including invokehttp.status.code
so, you could use RouteOnAttribute processor to redirect flow file to your external token processor only when invokehttp.status.code=401.
For my application when I record , each HTTP request has required Headers that are maintained at individual HTTP Header Manager.
Now an Authentication token is also managed in the Header manager for every request after login. For multiple users I pass variable for this Authentication token. To make this happen I need to edit in every Header(or I do it opening jmx file in Notepad++ and then replacing all). But is there any way like using a global HTTP header manager that will override over Sample lever Headers.
As per Using JMeter's HTTP Header Manager article:
JMeter now supports multiple Header Managers.
The header entries are merged to form the list for the sampler. If an entry to be merged matches an existing header name, it replaces the previous entry, unless the entry value is empty in which case any existing entry is removed. This allows one to set up a default set of headers, and apply adjustments to particular samplers.
If you don't like the situation you can uncheck "Capture HTTP Headers" box in the HTTP(S) Test Script Recorder
If all headers are same throughout the script then you can remove all individual headers which are currently child of http request samplers and keep only one header manager outside of all request which will act as a global header manager and it will pass values to all requests
I am hoping to get some clarification on the expected behavior of a SIP Proxy when proxying 401 responses from a downstream UAS.
Our SIP Proxy is configured to proxy requests downstream in a round-robin fashion. If the downstream UAS responds to an INVITE with a 401, I would expect the SIP Proxy to keep enough state to select this same UAS as the target when the originating upstream UAC sends the second INVITE containing authentication credentials.
Instead, what I'm seeing is that the SIP Proxy will proxy the 401 response, receive the ACK from the upstream UAC, and immediately destroy all state pertaining to this dialog. Then when the upstream UAC sends the second INVITE with authentication credentials the SIP Proxy will forward that request in round-robin fashion. If we get lucky then the SIP Proxy will select the same UAS for the second INVITE, but most of the time it will select some other downstream target.
I'm new to SIP and I've been reading RFC 3261 to try and understand what the correct behavior should be, but I'm not seeing an obvious answer.
I think what you are really asking is an understanding of how further requests within a dialog work. For that you need to understand the "Record-Route" / "Route" headers.
It really doesn't mater what the response code is, the next request in the dialog will go directly to the remote URI unless (and there almost always is) a route set provided.
From section 12 of RFC 3261:
The route set is the list of servers that need to be traversed to
send a request to the peer.
From section 16.6 Request Forwarding
4. Record-Route
If this proxy wishes to remain on the path of future requests
in a dialog created by this request (assuming the request
creates a dialog), it MUST insert a Record-Route header field
value into the copy before any existing Record-Route header
field values, even if a Route header field is already present.
From 20.34 Route
The Route header field is used to force routing for a request
through the listed set of proxies. Examples of the use of the
Route header field are in Section 16.12.1.
From 12.1.2 UAC Behavior
The route set MUST be set to the list of URIs in the Record-Route
header field from the response, taken in reverse order and preserving
all URI parameters. If no Record-Route header field is present in
the response, the route set MUST be set to the empty set. This route
set, even if empty, overrides any pre-existing route set for future
requests in this dialog.
From 16.12 Summary of Proxy Route Processing
In the absence of local policy to the contrary, the processing a
proxy performs on a request containing a Route header field can be
summarized in the following steps.
1. The proxy will inspect the Request-URI. If it indicates a
resource owned by this proxy, the proxy will replace it with
the results of running a location service. Otherwise, the
proxy will not change the Request-URI.
2. The proxy will inspect the URI in the topmost Route header
field value. If it indicates this proxy, the proxy removes it
from the Route header field (this route node has been
reached).
3. The proxy will forward the request to the resource indicated
by the URI in the topmost Route header field value or in the
Request-URI if no Route header field is present. The proxy
determines the address, port and transport to use when
forwarding the request by applying the procedures in [4] to
that URI.
See this example for how it works.
So basically the initial request should build up "Route-Set" that is then used to generate the "Route" header in the following request.
So for your problem, it sounds like either the "Route-Set" is not being built up and/or being sent back in the response or the UAC isn't using the remote target and route set to build the Request-URI and Route headers correctly for the next request.
There is also the difference between strict and loose routing which also may be in play here as well. I would assume you would be using lr tho.