fix: ignore Accept header to prevent UnknownFormat errors

[mroderick]

Summary

• Adds config.action_dispatch.ignore_accept_header = true to production environment
• Prevents ActionController::UnknownFormat errors when clients send non-HTML Accept headers (e.g., Accept: application/json)

Problem

Requests with non-HTML Accept headers cause server errors:

ActionController::UnknownFormat: ChapterController#show is missing a template for this request format and variant.
request.formats: [\"application/json\"]

Example error from production - AHC HTTP client requesting JSON:

curl -H \"Accept: application/json\" https://codebar.io/shanghai

Root Cause

Rails determines response format from (in priority order):

1. ?format= query parameter
2. HTTP Accept header ← The problem
3. URL path extension (.csv, .json)
4. Default to HTML

When a client sends Accept: application/json, Rails tries to render JSON. Without JSON templates, it raises UnknownFormat.

Solution

Single configuration change in config/environments/production.rb:

config.action_dispatch.ignore_accept_header = true

This tells Rails to ignore the HTTP Accept header for format negotiation. Format comes only from:

• ?format= query parameter
• URL path extension (.csv, .json)
• Default to HTML

How This Is Safe

What continues to work:

• CSV exports - /admin/events/1.csv (path extension)
• Text exports - /admin/events/1?format=text (query param)
• TomSelect member search - Uses /admin/members/search which explicitly renders JSON with render json:
• HTML pages - All normal browser requests

What gets fixed:

• JSON/other Accept headers → falls back to HTML instead of 500 error
• No more server errors that need investigation

Documentation

• Rails API: ActionDispatch::Http::MimeNegotiation#ignore_accept_header
• Rails API (instance method): use_accept_header
• Rails commit (2008): rails/rails#2f4aaed

From the original Rails commit:

"The accept header is poorly implemented by browsers and causes strange errors when used on public sites where crawlers make requests too."

This is the recommended approach for public websites per Rails core team.