Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to disable an S3 bucket redirect rule?

I have an S3 bucket that's hosting a Vue application which uses Vue Router with history mode enabled. Originally, I had the following redirect rule in place to work around S3 not being able to resolve "virtual" routes (based on this approach). It prefixes the path with a hash syntax which a script on the page identifies and strips, using history.pushState() to turn it back into a non-hashed path that history mode can understand.

<RoutingRules>
  <RoutingRule>
    <Condition>
      <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals>
    </Condition>
    <Redirect>
      <HostName>mydomain.com</HostName>
      <ReplaceKeyPrefixWith>#!/</ReplaceKeyPrefixWith>
    </Redirect>
  </RoutingRule>
</RoutingRules>

However, the more modern approach is to just let CloudFront do it by pointing 403 and 404 error pages at /index.html (based on this approach).

After setting up the CloudFront error pages, I've removed the redirect rule from the bucket and even the error document from the bucket. However, S3 continues to use the redirect rule and prefix my routes with #!/.

How can I force the redirect rule to stop operating?

like image 667
Soviut Avatar asked Oct 21 '25 17:10

Soviut


1 Answers

CloudFront invalidations work against the path the browser is actually requesting, not the path being requested from the origin (back-end) server.

Invalidating / would probably have worked in this case, but /* invalidates everything. Using /index.html (the console invisibly adds the leading / if you don't) would only clear the cache in the case where the browser was directly requesting /index.html.

CloudFront accepts invalidation requests even when they don't match anything, because an invalidation request is essentially a directive to ensure that no matching objects are in the cache. When the invalidation request completes, then that condition is true -- there are, at that point, no matching objects. Regardless of whether they were purged or were never there, the invalidation request can be said to have succeeded, because they are now gone... but a side effect of this is that you don't get a warning if you invalidate something that was never there.

like image 149
Michael - sqlbot Avatar answered Oct 23 '25 07:10

Michael - sqlbot