Can I remove default HTTP headers from a SOAPReply node?
I tried to Overwrite it in ESQL and tried removing it using HTTPHeader node, I succeded in creating new HTTP Headers but failed to remove the default ones (for example "Server: IBM App Connect Enterprise").
The weird thing is that the same code works with HTTPReply node but not with SOAPReply node. Any suggestions?
My ESQL code:
SET OutputRoot.HTTPReplyHeader."Server" = 'MyDummyValue';
Output of HTTPReply node:
HTTP/1.1 200 OK
Content-Type: text/xml
Server: MyDummyValue
Output of SOAPReply node:
HTTP/1.1 200 OK
Content-Type: text/xml
Server: IBM App Connect Enterprise
I tried to override it in the Integration Server YAML file (server.conf.yaml) and it worked as expected for both HTTP and SOAP flows.
The value you need to override is:
/ResourceManagers/HTTP[S]Connector/ServerName
I checked this page: https://www.ibm.com/docs/en/app-connect/11.0.0?topic=node-local-environment-overrides-soapreply and I cannot see any local environment override that would suppress the default headers in a SOAPReply node.
The Server header is in an internal list of headers that we don't allow you to set. I suspect it is to ensure that receiving clients know how to process the SOAP messages from ACE, we might have had a situation where it was overwritten and a client application failed, and it was added to the list.
Is there a particular reason why you need to modify the Server header?
Related
I am trying get past some unit test after upgrading from Microsoft.Azure.Blob to Azure.Storage.Blobs. My connection to BlobServiceClient is
// create service client:
var blobServiceClient = BlobServiceClient("UseDevelopmentStorage=true")
//create container
BlobContainerClient container = client.GetBlobContainerClient(containerName);
//my code blows up on 'container.exists()'...but I don't get read access error.
//RequestFailedException : "The value for one of the HTTP headers is not in the correct format."
if(!container.Exists())
container = client.CreateBlobContainer(containerName).Value;
BlobClient blobClient = container.GetBlobClient($"{blobName}.json");
await blobClient.UploadAsync(BinaryData.FromString(jsonContent), options);
Wondering if anyone knows if there is some limitation on using azurite and the latest libs?
checking my container it 'looks' to me like it is ok? I have tried using the provided connection strings from within Microsoft Azure Storage explorer as well and had the same issues. I can't understand what it means by my headers are incorrect. The other answers are related to functions and also gt 4 years old. I feel like this issue is something to do with my unit test setup.
The actual error message:
The value for one of the HTTP headers is not in the correct format.
RequestId:5b9f9072-606b-4dfa-b174-19ef2fa2c20d
Time:2023-01-27T00:02:23.357Z
Status: 400 (The value for one of the HTTP headers is not in the correct format.)
ErrorCode: InvalidHeaderValue
Additional Information:
HeaderName: x-ms-version
HeaderValue: 2021-10-04
Content:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Error>
<Code>InvalidHeaderValue</Code>
<Message>The value for one of the HTTP headers is not in the correct format.
RequestId:5b9f9072-606b-4dfa-b174-19ef2fa2c20d
Time:2023-01-27T00:02:23.357Z</Message>
<HeaderName>x-ms-version</HeaderName>
<HeaderValue>2021-10-04</HeaderValue>
</Error>
Headers:
Server: Azurite-Blob/3.17.1
x-ms-error-code: InvalidHeaderValue
x-ms-request-id: 5b9f9072-606b-4dfa-b174-19ef2fa2c20d
Date: Fri, 27 Jan 2023 00:02:23 GMT
Connection: keep-alive
Keep-Alive: REDACTED
Transfer-Encoding: chunked
Content-Type: application/xml
The error is happening because the Storage REST API version supported by your installation of Azurite (v3.17.1) is not the latest REST API version which is supported by the version of SDK (12.14.1) you are using.
To fix this issue, there are a few options:
Update your installation of Azurite to the latest version. Looking at Azurite releases, REST API version 2021-10-04 support is included in version 3.19.0.
Use cloud storage for development if possible. That way you will not run into these versioning issues.
Though not recommended but if you want to keep on using version 3.17.1 of Azurite, you would need to downgrade the SDK to a version that has support for the same REST API version.
I have a server in Azure running two web apps, one on port 443 (IIS), another on 1024 (Apache). Both are https. I have an Azure Application Gateway (WAF v2) in place. I would like to allow requests for subdomain1.domain.com to go through on 443 (which is set-up and working) and requests for subdomain2.domain.com to be re-written to port 1024 internally.
I have tried various combinations of conditions and actions, but cannot get anything to do anything at all, good bad or indifferent!
My current Condition is as follows
Type of variable to check: HTTP Header
Header type: Response Header
Header name: Common Header
Common header: Location
Case-sensitive: No
Operator: =
Pattern to match: (https?):\/\/.*subdomain2.domain.com(.*)$
My current action is:
Re-write type: Response Header
Action type: Set
Header name: Common header
Common header: Location
Header value: https://backendservername.domain.com:1024{http_resp_Location_2}
I can't find a combination that does anything at all, nor any examples that show port updates. I've tried using request headers and the host value, but unfortunately that conflicts with the host rewrite in the HTTP Settings that was necessary to get any end to end SSL working.
Thanks in advance.
Matt.
I am trying to upload a file using the PUT method, which is not including the file in the request. I have followed the other example POST methods, but considering PUT does not allow multipart to be checked, that might be the issue.
I am also using:
* httpClient4
* jmeter 3.3
screenshot : https://www.evernote.com/shard/s126/sh/b4ebf947-c7e4-4e0a-9ebf-8e42a5f5d082/6813671cb2ab7419
Request data:
PUT http://myurl----here/app_path/test__16525587b4361f339ca33a9cdf0e9201d90e76dc__1676871c-71b8-488a-9750-29554a4be722
PUT data:
[no cookies]
Request Headers:
Connection: close
Content-Type: application/octet-stream
Content-Length: 0
Host: int-cloudstore-perf.svc.netspot.com.au
User-Agent: Apache-HttpClient/4.5.3 (Java/9.0.1)
Your test does't seem to be sending anything as your Put data should not be blank.
I would recommend to remove data from the Parameter Name section of the "Files Upload" tab of the HTTP Request sampler as PUT method is different and it doesn't assume submitting an HTML form and most probably your request will start working as expected (at least it will send data to the server)
Just in case check out Testing REST API File Uploads in JMeter article
Just getting started with nifi.
Have an http processor of type "ListenHTTP" listening no port 9090
Need to allow http POST on http://localhost:9090/ end-point
I was unable to locate any "acceptable http verbs" settings within the Web UI for this processor, so my guess is - it needs to be specified in some sort of config file.
My question is: what file would that be, and what is the actual syntax to specify this?
I have seen some xml templates on line, but I'm not sure where to put one.
By default, if no alternative base name is specified, the ListenHTTP processor's endpoint is available at:
http://{hostname}:{port}/contentListener
Accordingly, your request should, for default settings, be:
curl --data "param1=value1¶m2=value2" localhost:9090/contentListener
The full documentation on the processor is available at ListenHTTP or if that link breaks, via the Nifi Documentation page.
Alternatively, if you were looking to restrict your endpoint to specific verbs consider the combination of HandleHttpRequest and HandleHttpResponse
I believe by default it will accept all verbs. I configured ListenHttp on port 9090 with an empty "Base Path" property, and was able to use curl to POST data to it successfully. What kind of issues are you having?
The ListenHTTP processor...
... starts an HTTP Server and listens on a given base path to transform
incoming requests into FlowFiles. The default URI of the Service will
be http://{hostname}:{port}/contentListener. Only HEAD and POST
requests are supported. GET, PUT, and DELETE will result in an error
and the HTTP response status code 405.
-- Nifi Documentation, ListenHTTP 1.6.0
I have been able to POST to Nifi using PowerShell with Invoke-WebRequest, but needed to specify -ContentType:"application/x-www-form-urlencoded". This content type is set implicitly in the curl command in the answer from #apiri.
The example below works, and as an added bonus shows how you might include a header that will set an attribute on the resulting flowfile. Remember that you need to set the optional HTTP Headers to receive as Attributes (Regex) property in the processor configuration.
[PS] $HttpPost = #{
Uri = "http://{hostname}:{port}/contentListener"
Method = "POST"
ContentType = "application/x-www-form-urlencoded"
Headers = #{MyAttribute = "SomeValue"}
}
[PS] $Body = Get-Content <some_file> -Raw
[PS] Invoke-WebRequest #HttpPOST -Body:$Body
VERBOSE: POST http://{hostname}:{port}/contentListener with -1-byte payload
VERBOSE: received 0-byte response of content type text/plain
StatusCode : 200
StatusDescription : OK
I have a program that uses an XMLHTTPRequest to gather contents from another web page.
Problem is, that web page has cloaking custom errors set-up (ie. /thisurl doesn't literally exist as a file on their web server, it is being generated by the custom 404 error file.), so its not returning the page it shows in the browser, instead its showing its default 404 error response from that custom error page, in my HTTPRequest response.
By using this website http://web-sniffer.net/ I have narrowed down what the problem may be, but I don't know how to fix it.
Web-sniffer has 3 different versions to submit the request:
HTTP version: HTTP/1.1
HTTP/1.0 (with Host header)
HTTP/1.0 (without Host header)`
When I use HTTP/1.1 or HTTP/1.0 (with Host header) I get the correct response (html) from the page. But when I use HTTP/1.0 (without Host header) it does not return the content, instead it returns a 404 error script (showing the custom error page).
So I have concluded that the problem may be due to the Host header not being present in the request.
But I am using MSXML2.XMLHTTP.3.0 and haven't been able to read the page using HTTP/1.1 or HTTP/1.0 (with Host header). The code looks like this:
Set objXML = Server.CreateObject("MSXML2.XMLHTTP.3.0")
objXML.Open "GET", URL, False
objXML.setRequestHeader "Host", MyDomain '< Doesnt work with or w/out this line
objXML.Send
Even after adding a Host header to the request, I still get the template of the 404 error returned by that custom error script in my response, the same as HTTP/1.0 (without Host Header) option on that web-sniffer site. This should be returning 200 OK like it does on the first two options on web-sniffer, and like in a web browser.
So I guess my question is, what is that website (web-sniffer.net) able to get the proper response with their first two HTTP version options, so I can emulate this in my app. I want to get the right page, but its only returning the 404 error from their 404 error template.
In response to an answerer, I have provided screen shots from 2 seperate cUrl requests below, one from each one of my servers.
I executed the same cURL command, same url (that points to a site on the main host), which is cURL -v -I www.site.com/cloakedfile . But looks like its not working on the main server, where it needs to be. It can't be a self-residing issue, because from secondary to secondary it works fine, these are both identical applications/sites, just different ip's/host names. It appears to be an internal issue, that may not be about the application side of things.
I dont have any idea bout MSXML2.XMLHTTP.3.0. But from you problem statement i understand that the issues is certainly due to some HTTP header field that is wrongly set or missed out in your request.
By default HTTP 1.1 clients set Host header. For example if you are connecting to google.com then the request will look like this
GET / HTTP/1.1
Host: google.com
The "Host" header should have the domain name of the server in which the requested resource is residing. Severs that has virtual hosting will get confused if "Host:" header is not present. This is what happens with groups.yahoo.com if you havent specified Host header
$ nc groups.yahoo.com 80
GET / HTTP/1.1
HTTP/1.1 400 Host Header Required
Date: Fri, 06 Dec 2013 05:40:26 GMT
Connection: close
Via: http/1.1 r08.ycpi.inc.yahoo.net (ApacheTrafficServer/4.0.2 [c s f ])
Server: ATS/4.0.2
Cache-Control: no-store
Content-Type: text/html; charset=utf-8
Content-Language: en
Content-Length: 447
And this should be the same issue you are facing with. And also make sure that you are sending the domain name of the server from which you are trying to fetch the resource. And the Host header should have a colon ":" to delimit the value like "Host: www.example.com".