idvb / middy-reroute Goto Github PK

Is it possible to run middy-reroute in a local invocation of a lambda function? (no s3 bucket)

The only header getting passed is the location header - there are multiple headers, including custom headers, whitelisted on the Cloudfront.

What values need to be added to the options block in order to pass on either specific headers or even all headers.

I'm implementing a new redirect solution for one of our many horrible systems. Unfortunately, one of our regions is still using ":" in it's html queries.

Example:
/footwear/ to http://www.website.com/local/search?text=Shoe&q=Shoe:relevance:gender:MALE

Is there anyway to escape those ":" characters in the _redirects file so they don't get automatically interpolated as undefined?

We're utilizing middy and middy-reroute for a redirector internally and so far it's working great. We went over the architecture with our AWS TAM and they recommended that instead of referencing an item in an S3 bucket directly, to reference a Cloudfront instead because it would be able to cache the S3 files, greatly speeding up the object access.

We're running into what we believe to be a few false positives from Pingdom, but, just in case, I want to pull together a prototype of that implementation to see if it makes a difference in response time.

Have you explored this method already? I would love to know your thoughts!

Upgrading from 2.4.1, I noticed all the reroute rules defined in the rule file stopped working.

S3 access log shows the rule file path from Middy Reroute is now prefixed with any prefix defined in the origin.
Here is an example:
const opts={
file: '_redirects/rule1",
rulesBucket: "bucket1"
}

origin is defined as "bucket1/sites"

In 2.4.1, the rule path used is "bucket1/_redirects/rule1"
in 2.5.4, the rule path used is "bucket1/sites/_redirects/rule1"

Is this a bug? The documentation seems to suggest the optional "rulesBucket" and "file" options should form the complete s3 path regardless how the origin is defined.