jill64
commented
4 months ago Thanks for opening this issue!
First, regarding the issue with CloudFront Functions (a.k.a. CF2) not logging, I have confirmed that this is also happening in the sample case.
However, my guess is that this is not a bug, but due to the CF2 specification.
CF2 is running on the original runtime based on ECMAScript 5.1 and may not support output beyond the second argument of console.log.
I will modify the adapter and see if this is the case.
Secondly, the reason why the CF2 Viewer-Request is needed is that it exists primarily for hostname canonicalisation. When using a custom domain, the application can be accessed by two hostnames.
For example, in the lambda-s3 sample case,
the application can be used under either of these hostnames.
In practice, however, it is preferable to normalise all requests to 2 for SEO reasons.
To do this, the 1 needs to be converted to 2 by an HTTP redirect before the request passes through CloudFront.
This is the need for Viewer-Request.
Do you know why event isn't logging?
Seems similar to this persons query:
https://stackoverflow.com/questions/76049017/in-my-lambdaedge-origin-request-function-the-event-parameter-is-empty
But I thought these functions would automatically get setup with service roles that allow logging.
Anyway, I wanted to view the logs to understand why it's necessary to have a viewer-request handler.
Before finding your package, I was running Sveltekit on Cloudfront, using SPA mode (which I still want to do, except for some server routes that I will use your handler for, e.g. /kit/server/* ). I didn't use (need?) a viewer-request, I just needed an origin-request that routed any misses on S3 to the svelte SPA fallback page.
Anyway nice package BTW. Due to the custom setup I need and the fact that my resources are deployed using a code pipeline (not CDK), I will probably end up having to pull out the bits of code I need, hence trying to understand all your moving parts.