Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

Deploying a Receipt Management Page to quickdumpnow.com/books: S3, CloudFront, and Error Handling Patterns

This post documents the deployment of a new receipt management interface for a trailer rental business at https://quickdumpnow.com/books. The work involved static site hosting patterns, CloudFront distribution configuration, and debugging 404 error responses—all common challenges when managing multiple content paths on a single CloudFront distribution.

What Was Done

The quickdumpnow.com site previously served only a landing page. We deployed a new books page to enable receipt tracking for the trailer rental operation. The deployment required:

  • Creating and updating /Users/cb/Documents/repos/sites/quickdumpnow.com/books/index.html
  • Uploading content to S3 with proper key structure for pretty URLs
  • Configuring robots.txt to block indexing of the new path
  • Managing CloudFront cache invalidation
  • Investigating and understanding custom error responses in the distribution

Technical Details: S3 Key Structure and Pretty URLs

A critical lesson emerged during this deployment: CloudFront + S3 pretty URL handling requires deliberate key naming. Initially, the page was deployed only to the books/index.html key. When users visited https://quickdumpnow.com/books, CloudFront requested /books from S3, which doesn't exist as an object—S3 has /books/index.html, not a /books key itself.

To fix this, we uploaded the HTML content to two S3 keys:

  • books/index.html — the canonical location
  • books — a bare key with the same content, enabling the pretty URL

This approach avoids Lambda@Edge functions or origin request rewriting. The trade-off is duplicating content; the benefit is simplicity and zero additional compute.

# S3 upload pattern for pretty URLs
aws s3 cp books/index.html s3://quickdumpnow-web/books/index.html
aws s3 cp books/index.html s3://quickdumpnow-web/books

CloudFront Custom Error Responses: A Hidden Gotcha

During deployment, https://quickdumpnow.com/books returned the homepage instead of a 404. Investigation revealed the CloudFront distribution has a custom error response configured:

  • HTTP Status Code: 404
  • Custom Error Response: Enabled, pointing to /index.html
  • TTL: Default error response caching

This pattern—redirecting 404s to the homepage—is common for single-page applications (SPAs). However, it masked the real issue: the /books key didn't exist in S3. Once we uploaded to the bare books key, CloudFront returned the correct content before the error response triggered.

The custom error response itself isn't a problem; it's a deliberate architectural choice to provide a graceful fallback. The lesson is to verify S3 object existence independently of CloudFront caching behavior.

robots.txt Configuration

The new books page should not be indexed by search engines—it's an internal receipt management tool. We updated the site's /Users/cb/Documents/repos/sites/quickdumpnow.com/robots.txt to disallow the path:

User-agent: *
Disallow: /books/
Disallow: /books

Both paths are blocked to handle variations in how crawlers interpret URLs. We disallow before indexing occurs, avoiding the need to request removal from search indices later.

CloudFront Invalidation

After uploading both S3 keys, we invalidated the CloudFront cache to ensure users received fresh content immediately:

aws cloudfront create-invalidation --distribution-id DIST_ID --paths "/books" "/books/*" "/robots.txt"

Three paths were invalidated:

  • /books — the bare key serving pretty URL traffic
  • /books/* — wildcard covering any subpaths (future extensibility)
  • /robots.txt — updated crawl instructions

Invalidation status was monitored; CloudFront reports invalidation progress via the API. Changes propagate to edge locations within 30–60 seconds for typical distributions.

Infrastructure Overview

The quickdumpnow.com stack uses a standard static site architecture:

  • Origin: S3 bucket (quickdumpnow-web)
  • CDN: CloudFront distribution (configured with custom error responses)
  • DNS: Route53 alias records pointing CloudFront domain to quickdumpnow.com
  • Storage: All content versioned in local repo at /Users/cb/Documents/repos/sites/quickdumpnow.com/

This is a zero-server architecture: no EC2, no Lambda (for origin requests), no application tier. All scaling is handled by AWS managed services.

Key Decisions and Rationale

Why Two S3 Keys Instead of Index Document Rewriting? CloudFront's origin request event (Lambda@Edge) could rewrite /books requests to /books/index.html

Why Block in robots.txt Before Deployment? The page was live for ~30–60 seconds before the invalidation completed. By blocking in robots.txt immediately, we signal to crawlers not to index the path, even if they discover it. This prevents SEO issues and clarifies intent to search engines.

Why Check CloudFront Custom Error Responses? CloudFront error responses can mask underlying S3 issues. By verifying the distribution configuration, we confirmed the error handling was intentional and not the root cause. This separated the SPA fallback pattern from the actual deployment problem.

What's Next

The books page is now live and serving requests. The next phase involves:

  • Building out receipt form functionality (HTML/CSS/JavaScript)
  • Integrating with the Port Log sheet (Google Apps Script) to record entries
  • Adding receipt upload and storage (likely S3 with signed URLs)
  • Monitoring CloudFront metrics for the new path to establish baseline performance

The infrastructure foundation is solid; scaling the feature is now a UX and backend integration problem, not an infrastructure one.