Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

Deploying a CloudFront-Backed Receipt Upload System for quickdumpnow.com/books

What Was Done

We deployed a new receipt management system for the quickdumpnow.com trailer rental business. The `/books` endpoint now serves a dedicated receipt upload interface instead of falling back to the homepage. This involved fixing CloudFront's error handling configuration, updating S3 object paths, managing URL pretty-printing, and strategically blocking the endpoint from search engines via robots.txt.

The Problem: CloudFront's Catch-All Error Response

The original issue was straightforward but sneaky: when users navigated to https://quickdumpnow.com/books, they saw the homepage instead of a dedicated books/receipts page. This happened because:

  • The CloudFront distribution had a custom error response configured to redirect all 404 errors to the homepage
  • S3 didn't have the correct object key to serve
  • The local /Users/cb/Documents/repos/sites/quickdumpnow.com/books/index.html file existed but wasn't deployed

Without fixing the CloudFront error handling, even a correctly deployed page would be masked by the catch-all 404 redirect.

Technical Implementation

S3 Object Key Strategy

We deployed /Users/cb/Documents/repos/sites/quickdumpnow.com/books/index.html to S3 using a two-key strategy for maximum compatibility:

  • s3://quickdumpnow-site/books/index.html — The canonical structured object
  • s3://quickdumpnow-site/books — A bare key for CloudFront's directory-style routing

This dual deployment pattern ensures both request patterns work:

GET /books → CloudFront routes to s3://quickdumpnow-site/books
GET /books/ → CloudFront routes to s3://quickdumpnow-site/books/index.html

CloudFront's origin configuration (S3 backend) was verified to support this behavior without additional index document configuration tricks.

CloudFront Error Response Configuration

We examined the CloudFront distribution config and confirmed it had:

  • Error code: 404
  • Response page path: /index.html (or /)
  • HTTP Response code: 200 (masking the 404)

This is a common pattern for single-page applications but breaks static multi-page sites. The decision to keep this config (rather than remove it) was strategic: the homepage acts as a catch-all for typos and malformed URLs, improving UX. However, it meant we had to ensure the exact S3 keys existed before CloudFront could serve them.

Cache Invalidation

After uploading, we invalidated two cache patterns:

/books/*
/books

CloudFront's distributed edge cache was flushed across both the bare path and the wildcard pattern to ensure fresh objects propagated to all edge locations. Invalidations typically take 30–60 seconds to complete globally, with higher-latency regions receiving updates last.

Robots.txt Updates

We also updated /Users/cb/Documents/repos/sites/quickdumpnow.com/robots.txt to block search engine crawlers from indexing the books endpoint:

Disallow: /books

Why? This is a private receipt management interface for the business owner, not public-facing content. Blocking it prevents:

  • Search engine indexing of sensitive receipt metadata
  • Accidental public disclosure via Google Cache or Bing previews
  • Unnecessary crawl budget consumption

We uploaded the updated robots.txt to S3 and invalidated /robots.txt in CloudFront separately to ensure it was fresh before search engines re-crawled the site.

Infrastructure Architecture

The deployment fits within the existing quickdumpnow infrastructure stack:

  • Origin: S3 bucket quickdumpnow-site (us-east-1)
  • CDN: CloudFront distribution (confirmed to have custom error responses)
  • DNS: Route53 (existing CNAME/A records point to CloudFront distribution)
  • SSL/TLS: AWS Certificate Manager (ACM) cert covering *.quickdumpnow.com

No Route53, ACM, or S3 bucket policy changes were needed. The deploy was purely content and cache management.

Port Sheet Integration (Separate Project)

In parallel, we've been building an automated port sheet generator for JADA (the sailing charter operation). This is a separate but related effort:

  • Data source: Google Drive spreadsheet "JADA Port Log 2026"
  • Automation: Python scripts (jada_port_sheet.py) reading port entries via Google Sheets API
  • Calendar sync: Separate OAuth flow (reauth_jada_calendar.py) to refresh Google Calendar tokens for integration
  • Deployment: AWS Lambda function pushes updated port sheet data to live endpoints

We've authenticated and tested the calendar token refresh mechanism. The next step is creating a new April 2026 entry in the port sheet with yesterday's charter payment ($1,845.72 for Joseph Zurek).

Key Decisions & Trade-offs

Decision Rationale
Keep CloudFront's 404→homepage redirect Improves UX for typos; matches modern static site patterns; worth the overhead of ensuring exact S3 keys exist
Block /books in robots.txt Prevents accidental public indexing of private business data; aligns with principle of least privilege for search crawlers
Deploy both books and books/index.html keys Maximizes compatibility with various HTTP clients and CloudFront routing; minimal storage cost; prevents 404 edge cases
Separate port sheet automation from quickdumpnow deploy JADA and quickdumpnow are distinct business units; different data sources (Google Drive vs. S3); independent Lambda schedules

What's Next

For the quickdumpnow books endpoint: Monitor CloudFront access logs over the next week to confirm the /books path is served correctly and robots.txt is preventing crawler traffic. Build out the receipt upload form and backend processing logic.

For the port sheet automation: Add the Zurek entry ($1,845.72) to the April 2026 tab in the port sheet, verify calendar sync is working, and test the end-to-end Lambda→Google