AWS API Gateway Custom Domain not passing the user-agent

Question

I have a custom domain example.com that is redirecting to my API gateway api-example.com, but it doesn't seem to pass the user-agent field, all my user-agent values are AmazonAPIGateway_5rfp2g9h9b.

If I call directly the api-example.com then it works fine, but if I call example.com, doesn't work.

Any idea on how I could pass the correct user-agent HTTP Header?

Thanks

Answer 1

It’s not clear what you mean by redirect or the domains you have listed, so you have two custom domains ? And if so how did you do that, Cloudfront with a custom origin? And what type of integration request do you have? Is this a REST or HTTP API? Probably why you are getting down voted because you don’t have any detail and the domains don’t make sense.

Either way in your API make sure you have the user-angent field defined where it is applicable:

• Request Part of your API, and make sure your integration request is forwarding this header
• Likewise make sure Cloudfront forwards the ‘user-agent’ header, that it is also whitelisted if you are using Cloudfront

Note this header comes from your Web browser or SDK being used sometimes sets this too. So if you don’t set this header for whatever reason that could be a problem, I don’t know if for example when you say from this domain that means you are using a hosted website, and another means making a request from Postman, etc.

Answer 2

Short answer: Validate the contents of your header

Ref AWS user-agent redirect here.. as listed below.

Redirects and HTTP user-agents:

..Programs that use the Amazon S3 REST API should handle redirects either at the application layer or the HTTP layer. Many HTTP client libraries and user agents can be configured to correctly handle redirects automatically; however, many others have incorrect or incomplete redirect implementations. Before you rely on a library to fulfill the redirect requirement, test the following cases:

• Verify all HTTP request headers are correctly included in the redirected request (the second request after receiving a redirect) including HTTP standards such as Authorization and Date.
• Verify non-GET redirects, such as PUT and DELETE, work correctly.
• Verify large PUT requests follow redirects correctly.
• Verify PUT requests follow redirects correctly if the 100-continue response takes a long time to arrive. HTTP user-agents that strictly conform to RFC 2616 might require explicit confirmation before following a redirect when the HTTP request method is not GET or HEAD. It is generally safe to follow redirects generated by Amazon S3 automatically, as the system will issue redirects only to hosts within the amazonaws.com domain and the effect of the redirected request will be the same as that of the original request...

---

Optional/Additional help, I was trying to understand your description, if you're going across domains, thats CORS.

1. Please consider CORS which you seem to be missing, please see configuration here.
2. Also very important you Enabling CORS support for a resource and its methods does not recursively enable it for child resources and their methods.
3. If you want to setup your custom header for user-agent

1. Setup CORS in Console

2. How to setup from console under the resources enable the CORS.

3. Setup your Headers

4. As a last step you have to REdeploy to a stage, for the settings to take effect!

Answer 3

From the Apache documentation

Apache Solr releases prior to 7.4 (i.e. Solr 5, Solr 6, and Solr 7 
through 7.3) use Log4J 1.2.17 which may be vulnerable for installations 
using non-default logging configurations that include the JMS Appender, 
see 

https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126 

for discussion.