Add inline image rendering for JSON responses with inlineData

[simonw]

Add a feature to cors-fetch.html such that if the response returns JSON it scans recursively through the nested JSON (arrays and objects) looking for this shape:

{
   “inlineData”: {
    “mimeType”: “image/png”,
    “data”: “iVBORw0KGgo…

And if it finds one or more objects like that it renders them as max-width:100% images below the JSON using images with src data URIs

Recursively scans JSON responses for objects with the shape:
{ inlineData: { mimeType: "image/...", data: "base64..." } }

Found images are rendered below the JSON output as max-width:100%
images using data URIs, with metadata showing the MIME type and
JSON path where each image was found.

https://gisthost.github.io/?eb6299cfaf5d4c8bdcdaffb233d3dbb0/index.html

[claude]

Claude finished @simonw's task —— View job

---

Code Review Complete ✅

Todo List:

• Read repository guidelines (CLAUDE.md) - No CLAUDE.md found
• Analyze the modified cors-fetch.html file
• Review code quality and best practices
• Check for potential bugs and edge cases
• Evaluate performance considerations
• Assess security concerns
• Review test coverage needs
• Provide comprehensive feedback

---

Review Summary

This PR adds functionality to automatically detect and render inline image data from JSON responses. The implementation scans JSON for objects with the specific shape { inlineData: { mimeType: "image/...", data: "base64..." } } and displays them as images below the JSON output.

Code Quality & Best Practices ✅

Strengths:

• Clean, well-structured JavaScript with clear function separation
• Good use of defensive programming (null checks, type validation)
• Consistent code style matching the existing codebase
• Proper HTML escaping to prevent XSS
• Recursive tree traversal with path tracking for debugging

Areas for improvement:

• Consider extracting magic strings like "inlineData" and "image/" as constants

Security Assessment ⚠️

Potential Issues:

1. Base64 validation missing (lines 809-814): The code doesn't validate that the data field contains valid base64. Malformed base64 could cause issues:

   // Current code trusts any string
   typeof obj.inlineData.data === "string"
   
   // Consider adding validation
   function isValidBase64(str) {
     try {
       return btoa(atob(str)) === str;
     } catch {
       return false;
     }
   }

2. Data URI size limits: Large base64 images could cause browser memory/performance issues. Consider adding size limits.

3. MIME type validation: While checking for "image/" prefix is good, consider validating against a whitelist of safe image types.

Performance Considerations ⚠️

1. Recursive traversal efficiency (lines 797-832): The findInlineImages function recursively scans the entire JSON tree. For very large JSON responses, this could be expensive.

2. DOM injection approach (lines 844-854): Using innerHTML with template strings is less efficient than creating DOM elements, but acceptable for this use case.

3. No image loading optimization: Large images are loaded immediately without lazy loading or size optimization.

Bug & Edge Case Analysis ✅

Well handled:

• Null/undefined object checks (line 800)
• Type validation for required fields (lines 805-809)
• Array vs object handling (lines 818-829)
• Path generation for nested structures (lines 820, 826)

Potential edge cases:

• Very deep JSON nesting could cause stack overflow, but this is unlikely in practice
• Circular references in JSON would cause infinite recursion (though JSON.parse prevents this)

Test Coverage Assessment ❌

Missing:

• No unit tests for the new functionality
• No integration tests for the image rendering
• No tests for edge cases (invalid base64, malformed objects, etc.)

Recommendations:

• Add tests for findInlineImages() with various JSON structures
• Test with invalid/malformed data
• Test rendering with different image types and sizes
• Test performance with large JSON responses

Specific Code Issues

1. Line 845: HTML escaping is correctly applied to metadata, but consider validating MIME types more strictly.

2. Lines 886-891: The conditional rendering logic is clean and well-structured.

3. Lines 494-530: CSS styling is appropriate and responsive.

Overall Assessment

This is a well-implemented feature that follows good practices. The code is readable, properly integrated with the existing UI, and handles most edge cases appropriately.

Priority recommendations:

1. High: Add base64 validation for security
2. Medium: Add basic test coverage
3. Low: Consider performance optimizations for very large responses

Approval recommendation: ✅ Approve with minor suggestions - The security concerns are minor and the feature works well as implemented.

---

[simonw]

Works great: