Skip to content

Match static file extensions case-insensitively - #2610

Closed
xop01 wants to merge 1 commit into
yhirose:masterfrom
xop01:fix-mime-extension-case
Closed

xop01 wants to merge 1 commit into
yhirose:masterfrom
xop01:fix-mime-extension-case

Conversation

@xop01

@xop01 xop01 commented Oct 3, 2026

Copy link
Copy Markdown

Summary

  • file_extension keeps the original case, and find_content_type switched on lowercase str2tag literals. index.HTML and a.JPG therefore fell through to application/octet-stream.
  • The extension is lowercased before the user-map lookup and the built-in switch. set_file_extension_and_mimetype_mapping stores the key in lowercase too, so a mapping registered as HTML matches .html and .HTML.

Test plan

  • find_content_type("dir/index.HTML") is text/html, and a.JPG is image/jpeg
  • A user map keyed by abcde matches f.ABCDE
  • FindContentTypeTest.ExtensionCaseIsIgnored
  • ServerTest.UserDefinedMIMETypeMapping still passes

index.HTML and photo.JPG missed the built-in MIME table, which is keyed by lowercase tags, and were served as application/octet-stream.

Co-authored-by: Cursor <cursoragent@cursor.com>
@yhirose

yhirose commented Oct 3, 2026

Copy link
Copy Markdown
Owner

Thanks for the PR. Matching extensions case-insensitively would change the Content-Type served for existing files, which affects current users. I'd prefer to keep the current behavior unless there is a concrete need. Closing.

@yhirose yhirose closed this Oct 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants