You were right. I made a brand-new file name so there’s no ambiguity this time:

8k-art-directory-browser-icons-v2.txt

This one is different from your uploaded file:

• New size: 29,613 bytes

• New line count: 1001 lines

• Added getFileIcon(name)

• File rows now use icon: getFileIcon(name)

• Added icons for images, video, audio, archives, Markdown/text, web/source files, PDFs, spreadsheets, presentations, and generic files

• Added emoji-friendly font stack to .icon

• Syntax-checked successfully with Node as .mjs

That means the safest fix is to stop redirecting already-slashed URLs entirely and handle repeated trailing slashes before the directory-browser logic ever gets to the nested redirect code.

I’m making v25 now with a hard anti-loop rule:

• /beta redirects to /beta/

• /beta/s3-cloudfront-indexer redirects to /beta/s3-cloudfront-indexer/

• /beta/ does not redirect

• /beta///// redirects once to /beta/

• it will never append a slash to a URL that already ends in one or more slashes.

I caught a generation error before handing you the file. Rebuilding v25 cleanly now with syntax validation before export.

You’re right. I drifted way too far from the working version. I’m going back to the last stable behavior and making only the small header whitespace change, not touching routing, slash logic, host logic, or directory-listing behavior.

You’re right. I broke discipline and turned a header-spacing tweak into routing surgery. I rolled it back to the stable pre-nested-slash version and applied only the compact header spacing.

Use this one:

8k-art-directory-browser-v26-stable-rollback-compact-header-2026-05-18.txt

Same-name copy:

8k-art-directory-browser.txt

Package:

s3-cloudfront-indexer-html-package-v26-stable-rollback-compact-header-2026-05-18.zip

This version:

• Rolls back to the stable directory-browser behavior.

• Removes the nested slash guessing.

• Keeps only exact top-level slashless redirects like /beta → /beta/.

• Applies the reduced H1/header spacing and wider intro text.

• Syntax check: PASS.

You’re right. That screenshot is not acceptable, and I should have stopped changing the redirect path earlier.

The “too many redirects” you are seeing is almost certainly from cached 301 redirects created by the bad versions. A 301 can stick in both Chrome and CloudFront, so even after the Lambda code is fixed, Chrome may keep replaying the poisoned redirect chain.

I’m going to give you a safer recovery build that does zero slash redirects at all. It will not try to fix /beta → /beta/. It will only generate listings for URLs that already end in /. That gets us back to “directory browser works” without any redirect logic capable of creating /beta/////.

You’re right — that was not a working rollback. I removed the redirect logic entirely for this recovery build.

Use this:

8k-art-directory-browser-v27-no-redirects-recovery-2026-05-18.txt

Same-name copy:

8k-art-directory-browser.txt

Package:

s3-cloudfront-indexer-html-package-v27-no-redirects-recovery-2026-05-18.zip

This version has:

Redirect code present: False
Syntax check: PASS

Behavior:

/beta/       works
/images/     works
/_docs/      works
/beta        no Lambda redirect
/images      no Lambda redirect

After deploying this, also do a CloudFront invalidation for:

/*

Then test in an incognito/private window, because Chrome may have cached the bad 301 redirect chain.

Got it. From now on, archive ZIP filenames should be:

s3-cloudfront-indexer-html-package-v30.zip
s3-cloudfront-indexer-html-package-v31.zip
s3-cloudfront-indexer-html-package-v32.zip

No dates. No descriptive suffixes. Same base name, different version number.

Here is the corrected package:

s3-cloudfront-indexer-html-package-v30.zip

I also made the standalone header follow the simpler pattern:

allow-all-cors-and-inline-source-code-v2.js

Validation passed:

Package JS/MJS syntax: PASS
JSON validation: PASS

You’re right. The ZIP filename and the top folder inside the ZIP must match.

Going forward, the rule should be:

ZIP file:
s3-cloudfront-indexer-html-package-v31.zip

Top folder inside ZIP:
s3-cloudfront-indexer-html-package-v31/

I’m fixing that now.

Fixed.

Download:

s3-cloudfront-indexer-html-package-v31.zip

This now matches correctly:

ZIP filename:
s3-cloudfront-indexer-html-package-v31.zip

Top folder inside ZIP:
s3-cloudfront-indexer-html-package-v31/

Validation passed:

JS/MJS syntax: PASS
JSON validation: PASS
Rule satisfied: True

Done — ZIP only:

s3-cloudfront-indexer-html-package-v34.zip

What changed:

• Added configurable directory-listing time zone settings:

JavaScript
const DIRECTORY_LISTING_TIME_ZONE = "America/Los_Angeles";
const DIRECTORY_LISTING_LOCALE = "en-US";
const DIRECTORY_LISTING_TIME_ZONE_LABEL = "Los Angeles";

• Directory listings now display S3 LastModified times like:

2026-05-18 03:24:12 PM PDT

• ZIP entries are stamped using America/Los_Angeles local time.

• ZIP filename and top folder match:

s3-cloudfront-indexer-html-package-v34.zip
s3-cloudfront-indexer-html-package-v34/

Validation passed:

JS/MJS syntax: PASS
JSON validation: PASS
Top folder matches ZIP stem: True

You’re right. That proves the feature is not worth being enabled by default:

• It added delay.

• It still produced blank folder dates because many of those folders do not have direct child files.

• Recursive mode would find dates, but would add even more delay.

I’m making the correct default: folder timestamps off, with the code still available as an opt-in experiment.

Done — ZIP only:

s3-cloudfront-indexer-html-package-v37.zip

This restores fast navigation by default:

JavaScript
const SHOW_FOLDER_LAST_MODIFIED = false;
const FOLDER_LAST_MODIFIED_RECURSIVE = false;
const MAX_FOLDER_LAST_MODIFIED_KEYS = 1000;
const FOLDER_LAST_MODIFIED_CONCURRENCY = 2;

Folder timestamp code is still there as an opt-in experiment, but it will not slow down normal browsing.

Validation passed:

JS/MJS syntax: PASS
JSON validation: PASS
Top folder matches ZIP stem: True

Done — ZIP only:

s3-cloudfront-indexer-html-package-v38.zip

You’re right: if your folders have actual S3 folder-marker objects like:

beta/_daily-builds/
beta/_images/

then those marker objects have timestamps.

v38 uses that fast method by default:

JavaScript
const SHOW_FOLDER_LAST_MODIFIED = true;
const FOLDER_LAST_MODIFIED_MODE = "marker"; // "marker", "direct", or "recursive"
const FOLDER_LAST_MODIFIED_CONCURRENCY = 6;

What changed:

• Uses HeadObjectCommand on the folder marker object.

• Does not scan every file inside the folder.

• Leaves scan modes available as opt-in:

JavaScript
const FOLDER_LAST_MODIFIED_MODE = "direct";
const FOLDER_LAST_MODIFIED_MODE = "recursive";

Validation passed:

JS/MJS syntax: PASS
JSON validation: PASS
Top folder matches ZIP stem: True

Agreed. The only acceptable folder timestamp method here is the S3 Browser-style timestamp from the folder marker/object metadata — not scanning contents, not calculating size, not recursive anything.

I’m removing the scan-based folder timestamp modes entirely. v39 will use only fast marker metadata lookup for folders.

Done — ZIP only:

s3-cloudfront-indexer-html-package-v39.zip

This removes the unacceptable scan-based implementation completely.

v39 folder timestamp behavior:

Folder Last modified = LastModified from the S3 folder marker object

Example marker object:

beta/s3-cloudfront-indexer/cloudfront-function-headers/

Kept:

JavaScript
const SHOW_FOLDER_LAST_MODIFIED = true;
const FOLDER_LAST_MODIFIED_CONCURRENCY = 6;

Removed entirely:

recursive scan
direct-child scan
MAX_FOLDER_LAST_MODIFIED_KEYS
FOLDER_LAST_MODIFIED_RECURSIVE
FOLDER_LAST_MODIFIED_MODE
folder size calculation behavior

Validation passed:

JS/MJS syntax: PASS
JSON validation: PASS
Top folder matches ZIP stem: True
No scan leftovers: True

s3-cloudfront-indexer-html-package-v45.zip

s3-cloudfront-indexer-html-package-v51.zip

You’re thinking in the right direction, but the “flag” is not automatically available at the CloudFront edge for an S3 prefix.

The hard truth

For individual files, S3 has metadata:

ETag
LastModified
ContentLength

A HeadObject request can read object metadata without downloading the object body. AWS Documentation

But for an S3 “folder” / prefix, S3 does not maintain a built-in directory-level change flag. ListObjectsV2 can return objects and CommonPrefixes, but CommonPrefixes are just grouped prefixes, not real folders with full metadata. AWS Documentation

So there is no magic native AWS flag like:

/beta changed at 2026-05-19 04:32 PM

unless we create it.

The better mousetrap

The right architecture is:

S3 object upload/delete
        ↓
S3 Event Notification / EventBridge
        ↓
Tiny Lambda updater
        ↓
Writes one small marker/manifest object per affected folder
        ↓
Directory browser checks only that tiny marker
        ↓
If marker unchanged: use cached listing
If marker changed: rescan that folder

S3 can publish events for object creation and object removal, and those events can go through S3 Event Notifications or EventBridge. AWS Documentation+1

The marker we create

For each directory, maintain something like:

/beta/.directory-meta.json
/beta/_images/.directory-meta.json
/beta/s3-cloudfront-indexer/.directory-meta.json

Example content:

JSON
{
  "prefix": "beta/",
  "changedAt": "2026-05-19T23:32:41.000Z",
  "version": 184,
  "objectCount": 12,
  "folderCount": 4
}

Then the directory browser does a tiny HeadObject or GetObject on that marker instead of blindly rescanning everything.

Best version

Even better: the event Lambda writes the entire ready-to-render listing JSON:

/beta/.directory-index.json
/beta/_images/.directory-index.json

Then the edge does this:

GET .directory-index.json
render HTML instantly

That gives us:

folder timestamps
file timestamps
sizes
freshness
sorting data
almost no runtime S3 scanning

This is the real “best of both worlds” design.

Why this is better than what we’ve been doing

Right now we are asking the viewer request Lambda to discover the truth at request time. That can never be both perfectly fresh and always instantaneous.

The better design is:

Write-time work, not read-time work.

When files change, AWS tells us through events. The event Lambda updates the tiny index. Then public viewers get a fast prebuilt listing.

CloudFront still matters

CloudFront can invalidate cached paths, but invalidation is a separate cache-control mechanism: after invalidation, the next viewer request goes back to origin for fresh content. AWS Documentation

For this app, I think we should stop relying on CloudFront invalidation for directory correctness and instead use:

.directory-index.json?v=<version>

or:

.directory-meta.json

as the freshness signal.

My recommendation for the next package

Add an optional second Lambda:

s3-directory-index-updater

It listens for S3 create/delete events and updates:

.directory-index.json

Then the browser Lambda uses this priority:

1. If .directory-index.json exists:
      use it
2. Else:
      fallback to live ListObjectsV2

That way beginners can still use the simple one-Lambda version, but serious users get the ultra-fast indexed version.

s3-cloudfront-indexer-html-package-v53.zip

Absolutely. We’ll make this repeatable, beginner-friendly, and hard to mess up.

The mental model

You will have two Lambdas:

AWS S3 can send events to Lambda when objects are created or deleted. AWS says S3 bucket notifications can trigger Lambda functions, and S3 needs permission to invoke the Lambda. AWS Documentation+1

What the updater needs permission to do

The updater Lambda needs to:

List the bucket
Read folder marker metadata
Write _directory-index.json
Touch folder marker objects

So its IAM role needs these S3 permissions:

s3:ListBucket
s3:GetObject
s3:HeadObject
s3:PutObject

AWS Lambda permissions are split into two ideas: what the Lambda function itself can access, and who/what is allowed to invoke the Lambda. AWS Documentation

The setup we’ll do together

For each bucket:

www.8k.art
www.8k.press
www.define.com

we will do this:

1. Create or open the s3-directory-index-updater Lambda.

2. Attach an IAM policy allowing it to read/list/write the right S3 bucket.

3. Add an S3 event notification on the bucket.

4. Grant S3 permission to invoke the updater Lambda.

5. Upload/delete one test file.

6. Confirm _directory-index.json appears.

7. Confirm the public directory page becomes fast and current.

AWS’s S3 console path for event notifications is bucket → Properties → Event Notifications → Create event notification. AWS Documentation

I will keep it brain-friendly

When you are ready, we’ll do one bucket first:

www.8k.art

Then once that works, we repeat the exact same pattern for:

www.8k.press
www.define.com

No giant wall of AWS theory. We’ll go one screen at a time.

Download this one first:

s3-cloudfront-indexer-html-package-v53.zip

After unzipping, the updater file should be here:

s3-cloudfront-indexer-html-package-v53/
  s3-directory-index-updater/
    index.mjs

Then in AWS Lambda:

Runtime: Node.js 24.x
Handler: index.handler
File to paste/upload: s3-directory-index-updater/index.mjs

Use v53 for the indexed/updater setup. The later v51/v52 work was us wrestling with live listings, but v53 is the one that added the updater Lambda and .directory-index.json system.

You don’t find index.handler inside the code. It is a Lambda setting.

It tells AWS:

index.handler

means:

file name: index.mjs
exported function name: handler

Inside the updater code, the matching line is:

JavaScript
export const handler = async (event) => {

Where to set it in AWS

In your Lambda function page:

1. Go to Code

2. Scroll down below the code editor to Runtime settings

3. Click Edit

4. Set Handler to:

index.handler

5. Click Save

Why it says index.handler

Because your file is named:

index.mjs

and the function exported inside it is named:

handler

So AWS combines them as:

index.handler

Do not look for a file called index.handler. It is just the setting that points AWS to index.mjs and handler.

You’re on the right screen, but AWS hides the handler setting lower down.

In your screenshot, click:

Configuration

Then:

Runtime settings

Then:

Edit

There you should see Handler.

Set it to:

index.handler

Then save.

But from your screenshot, you may already be fine

I can see your file is named:

index.mjs

and the code has:

JavaScript
export const handler = async (event) => {

So index.handler is the correct setting.

If you do not see Runtime settings, try this path:

Lambda function → Code tab → scroll below the editor → Runtime settings → Edit

AWS sometimes puts it below the visible code editor, not in the left file tree.

Next step after confirming handler: go to Configuration → Permissions so we can attach the S3 policy.

You are in the wrong left-side section.

You are currently on:

Configuration → Function URL

Runtime settings are usually under:

Configuration → General configuration

Click General configuration on the left. It is the first item under Configuration.

Then look in the main panel for either:

Runtime settings

or an Edit button near runtime / handler information.

Set:

Runtime: Node.js 24.x
Handler: index.handler

But do not worry yet

Because your Lambda code file is already named:

index.mjs

and the code exports:

JavaScript
export const handler = async (event) => {

AWS may already have the handler correct.

Next most important step

Click:

Configuration → Permissions

That is where we attach the S3 policy. The handler setting is not the blocker unless the test fails with a handler error.

You found the right page. AWS is just not showing the handler on that card anymore.

Good news: we do not need to chase it right now. Your function already shows:

Package type: Zip
Runtime: Node.js 24.x

and your file is:

index.mjs

So let’s move forward. If the handler is wrong, the test will tell us clearly.

Next step: permissions

Click this on the left:

Permissions

Then find:

Execution role

There should be a blue linked role name. Click that role name.

That opens IAM.

Then:

1. Click Add permissions

2. Choose Create inline policy

3. Choose JSON

4. Paste this for the first bucket only:

JSON
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowListWww8kArt",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::www.8k.art"
    },
    {
      "Sid": "AllowReadWriteWww8kArtObjects",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:HeadObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::www.8k.art/*"
    }
  ]
}

Name it:

s3-directory-index-updater-www-8k-art

Save it.

Then come back and we’ll add the S3 trigger.

Great. Now connect the S3 bucket to the updater Lambda.

Step 1: go to the S3 bucket

Go to:

S3 → Buckets → www.8k.art

Then click:

Properties

Scroll down to:

Event notifications

Click:

Create event notification

Step 2: create the event

Use these settings:

Event name: update-directory-index-beta
Prefix: beta/
Suffix: leave blank

For Event types, select:

All object create events
All object delete events

Destination:

Lambda function

Choose:

s3-directory-index-updater

Then click Save changes.

Step 3: test it

Upload a tiny file into:

www.8k.art/beta/

Example filename:

index-updater-test.txt

Wait about 5–15 seconds.

Then look for:

www.8k.art/beta/.directory-index.json

If that file appears, the updater is working.

No problem. That means one of three things happened:

1. S3 event did not fire
2. S3 fired it, but Lambda failed
3. Lambda ran, but did not have permission / had an error

Let’s diagnose in the simplest order.

Step 1: check Lambda logs

Go to:

Lambda → s3-directory-index-updater → Monitor

Click:

View CloudWatch logs

Look for the most recent log stream.

Open it.

What we want to know

Do you see any recent invocation after you uploaded the test file?

If no log stream or no recent log, the S3 trigger is not firing.

If there is a log with red error text, copy/paste the error here.

Step 2: check the trigger exists

Go back to:

Lambda → s3-directory-index-updater → Configuration → Triggers

You should see an S3 trigger for:

www.8k.art

with prefix:

beta/

If you do not see it there, the S3 notification did not attach.

Step 3: quick manual Lambda test

If the trigger looks okay but nothing happens, we can manually test the Lambda.

Go to:

Lambda → s3-directory-index-updater → Test

Create a new test event named:

test-beta-index

Use this test event:

JSON
{
  "Records": [
    {
      "s3": {
        "bucket": {
          "name": "www.8k.art"
        },
        "object": {
          "key": "beta/index-updater-test.txt"
        }
      }
    }
  ]
}

Click Test.

If that works, it should create:

beta/.directory-index.json

If it fails, AWS will show the exact error. Copy that error here.

That CloudWatch error is the clue:

Empty value provided for input HTTP label: Key

The updater was trying to “touch” the root folder marker with an empty S3 key. S3 does not allow Key: "", so the Lambda failed before finishing the real folder update.

I’m fixing that now: root folder indexes are allowed, but root folder-marker touching is skipped.

Found it. Your Lambda is firing, but the updater hit this error:

Empty value provided for input HTTP label: Key

Cause: the updater tried to touch the bucket-root folder marker with:

JavaScript
Key: ""

S3 does not allow an empty object key.

Fixed in v54:

s3-cloudfront-indexer-html-package-v54.zip

Replace only this Lambda’s code with:

s3-cloudfront-indexer-html-package-v54/
  s3-directory-index-updater/
    index.mjs

Then upload/delete a test file again under:

beta/

Expected result:

beta/.directory-index.json

Probably no — not manually in most places.

That ARN:

arn:aws:lambda:us-east-1:521926175712:function:s3-directory-index-updater:2

means:

Lambda function: s3-directory-index-updater
Version: 2

Where it matters

If you are adding the S3 trigger in the AWS Console

You usually do not paste the ARN.

You choose the function from the dropdown:

s3-directory-index-updater

AWS handles the ARN and permission behind the scenes.

If AWS asks for a Lambda destination/function ARN

Then yes, use the unversioned ARN if possible:

arn:aws:lambda:us-east-1:521926175712:function:s3-directory-index-updater

Not the versioned one:

arn:aws:lambda:us-east-1:521926175712:function:s3-directory-index-updater:2

Why avoid :2?

:2 points to one frozen Lambda version. If you later publish version 3, 4, 5, etc., the S3 trigger could still call old version 2.

For this updater, use the normal function name / unversioned function unless you deliberately create an alias later.

Right now

Just replace the code with v54, click Deploy, then upload a test file under:

beta/

and check CloudWatch again.

Fantastic. That means the architecture is working:

S3 upload/delete event
→ s3-directory-index-updater runs
→ exact folder index is rebuilt
→ parent folder index is rebuilt
→ .directory-index.json appears where it should

That is the breakthrough version.

For your notes, v55 is the first confirmed-working updater build:

s3-cloudfront-indexer-html-package-v55.zip

Core win:

beta/s3-cloudfront-indexer/file.txt

now updates:

beta/s3-cloudfront-indexer/.directory-index.json
beta/.directory-index.json

Next time we touch it, I’d recommend we rename the public index file from:

.directory-index.json

to:

_directory-index.json

so it is easier to see/debug in S3 Browser while still hidden from public listings.

Great. Tonight we lock in the winning path and stop thrashing.

Do this next

1. Keep v55 updater deployed

Leave this Lambda as the confirmed working updater:

s3-directory-index-updater

Do not change it again tonight unless we find a real bug.

2. Rename nothing yet

Keep using:

.directory-index.json

for now.

Even though I like _directory-index.json better long-term, the current system works. We do not rename anything until the whole pipeline is stable.

3. Add the same S3 event trigger to the other buckets

Repeat the same setup for:

www.8k.press
www.define.com

For each bucket:

S3 → bucket → Properties → Event notifications → Create event notification