I am facing difficulties in overriding the list of HTTP Response headers listed below
X-Content-Type-Options (from 1 to nosniff)
X-Frame-Options (from SAMEORIGIN to deny)
Set-Cookie (add HttpOnly;Secure)
I have tried to put these values into the Listener's HTTP Response headers as well as utilizing the Header Removal and Header Injection in the API Manager policies but to no success in overriding to the intended values.
May I know how do override the HTTP Response headers? Kindly refer to the photo of the values that I have set.
API Policies
Header Removal
Header Injection
Listener's response header values in the mule project
Response header from the API call
These headers "X-Content-Type-Options", "X-Frame-Options" are injected by DLB, so not able to remove or modify at Mule app or policy level, unless not using DLB. MuleSoft has fixed it and should be available in their next release.
In the API Manager policies, use the Inbound Header Map instead of the Outbound Header Map for both header removal and injection.
Related
IntelliJ has an HTTP client. When composing a file that is interpreted by the HTTP client, you can specify headers that go out to the server with the request, like so:
###
GET https://{{hostname}}/{{path}}
Content-Type: application/json
X-Auth-Token: {{x-token}}
I want to find the actual value of the token that was used to replace the variable name, seen above as {{x-token}}, but I don't see any way to obtain the request headers. The response headers are obviously available, but not the request headers. See the image below for the test results that are shown after running the HTTP client inside Intellij:
Is there a way to display the REQUEST headers?
Link to IntelliJ Documentation - HTTP Client -- the documentation seems to never mention the actual request headers that are sent over the wire, but they do discuss how to define request headers in composing the .http file type.
Check the Tools | HTTP Client | 'Show HHTP Requests History' action.
I have a use case where I have to send content-length in the request header for only http2 calls.
After setting content-length for all calls, in case of http1.1, it is throwing below exception,
Caused by: org.apache.hc.core5.http.ProtocolException: Content-Length header already present
at org.apache.hc.core5.http.protocol.RequestContent.process(RequestContent.java:103)
Even after adding the last request interceptor to add length-content at last level, It is throwing same exception looks like the last interceptor is not the last interceptor.
I have also tied to put some protocol version based check but again the version it tells is incorrect, says http1.1 thought actually it is http2.
I am using httpclient5 library.
Unfortunately HttpClient 5.1 fails to set the negotiated HTTP protocol version in the execution context correctly due to HTTPCLIENT-2200 [1]. The issue will be resolved in upcoming HttpClient 5.2-beta1.
For now use a custom header (X-Content-Length) for all protocol versions.
[1] https://issues.apache.org/jira/browse/HTTPCLIENT-2200
Section 4.1.1. Authorization Request states:
The client constructs the request URI by adding the following
parameters to the query component of the authorization endpoint URI
using the application/x-www-form-urlencoded format, per Appendix B:
The use of the Content:Type x-www-form-urlencoded forces the request parameters to be sent in the body and not the query header. However, when submitted this way the authorization server returns an error indicating it cannot locate the client_id.
Is there a setting I need to change to support the request in the body rather than in the header?
I am trying to use the Aurelia HttpClient to call the TagniFi API on a different domain (and authenticating). The relevant code is:
return this._httpClient.createRequest(uri)
.asGet()
.withCredentials(true)
.withHeader('Access-Control-Allow-Origin', 'localhost:9000')
.withHeader('Authorization', 'Basic <my-key>')
.send();
I do receive a status 200 from the API, but I get the following error:
Response to preflight request doesn't pass access control check: A >wildcard '*' cannot be used in the 'Access-Control-Allow-Origin' header >when the credentials flag is true. Origin 'http://localhost:9000' is >therefore not allowed access. The credentials mode of an XMLHttpRequest >is controlled by the withCredentials attribute.
I am not sure if this is a error in the way I am making the call or a bug in Aurelia. Any help is appreciated. Thanks.
The Access-Control-Allow-Origin is an header sent in the response by the server and in your case you use it in the request from the client.
It's not a bug in Aurelia but a misuse of CORS.
See this excellent answer for more information on CORS.
Does anyone know how to get access to request HTTP headers within MessageEncoder.ReadMessage method?
It seems that WCF already "knows" request headers at the point of invoking ReadMessage method, at least Content-Type and Content-Length but I cannot get the access to the Content-Encoding header.
Basically, I'm trying to utilize gzip de/compression for WCF service (http://msdn.microsoft.com/en-us/library/ms751458.aspx) and would like to check if decompression is necessary for incoming request. To do that I'd like to check Content-Encoding header but cannot figure out where to get it.
Any ideas?
Thanks!
Here's an answer I gave in another thread which explains how you would need to manipulate the headers via the WebOperationContext in another IOperationBehavior which is coupled with the MessageEncoder.