add /_extension to well-known path prefixes to avoid s3 fallback handling #11796
Conversation
S3 Image Test Results (AMD64 / ARM64) 2 files 2 suites 3m 45s ⏱️ Results for commit 3f783ca. |
There was a problem hiding this comment.
Ah, good catch! Looking at this, I wonder if we often have the case that we have edge routes that actually need to have the service, especially since it does not have access to the request context. I think we'd be almost ready to move the service name parser after the edge routes to be honest, as the CORS detection does not rely on the services anymore (managed for S3 and APIGW, with some heuristics).
It doesn't really change anything to this particular issue though, but it made me think that maybe we could have a way to register some base path in our edge router (similar to Flask Blueprints somehow) so that we could return some default values when hitting some base path, instead of continuing the chain and having those hardcoded rules. I can see the issues we could get with that, as it'd be maybe difficult to dynamically add routes to those "blueprints".
But yeah, maybe we should think about registering rules for those base endpoints, so that we could avoid those tricks? What do you think?
In any case, this is a good fix and good to merge! 👌
edit: also, as a nit, I think it's not really a S3 fallback handler anymore since we removed the proxy listeners, just that those requests fit the routing rules of the S3 specs which are extremely greedy 😄
|
all great points @bentsku! thanks for greenlighting this, while also noticing some systemic issues we're not addressing here. definitely let's rework this soon! |
Motivation
Over time we've made
/_extensiona well-known path prefix, similar to/_awsor/_localstack, which still suffers from S3 xml errors when calling URLs within the/_extensionsubmount that don't exist. This is a band aid fix for that.Changes
/_extension/<path>are now no longer handled by the s3 fallback handler