Content-Disposition headers

[Myestery]

Update Content-Disposition header to include 'inline' for image responses.

meant to fix #8914

Old Behaviour

As seen in the linked issue, when Content Disposition is fetched for an image using the view_image function, it is erroneous to parse as it doesn't follow RFC standard

New Behaviour

Standard RFC pattern for Content Disposition is used to render images inline in the browser ( 100% backwards compatible as this is the browser's default)

[OrangeDoro]

Hi! I'm a grad student working on a research project about using large language models to automate code review. Based on your commit 3e53e19 and the changes in server.py, my tool generated this comment:

1. Filename Handling: Sanitize the filename variable to ensure it does not contain malicious characters or patterns to prevent vulnerabilities such as directory traversal attacks or header injection.
2. Error Handling: Implement proper error handling to manage cases where the image file cannot be processed or opened, ensuring that error messages do not leak sensitive information.
3. Null Checks for filename: Add a check for filename to ensure it is a valid string before constructing the headers.
4. Handling of request.rel_url.query: Ensure that request.rel_url.query is valid and handle cases where it might not be as expected.
5. Content-Disposition Header Change: Ensure that the change from attachment to inline aligns with the intended behavior of the application. If users expect to download images, consider retaining the attachment disposition.
6. Consistency Across Responses: Confirm that the change to inline is desired for all instances of the Content-Disposition header in the function.
7. Buffer Management: Implement limits on the size of the images that can be processed and served. Consider using streaming responses for large files to avoid loading the entire file into memory at once.
8. Common Logic: Create a helper function to handle the response creation to reduce code duplication and enhance readability.
9. Response Type Tests: Add tests to validate the response type based on the image format and ensure that the correct content_type is returned for different image formats.
10. Behavioral Tests for Different Channels: Add tests that cover different channel types (e.g., 'rgba', 'a') to ensure that the correct response is generated for each.
11. Testing: Ensure that there are tests in place to verify that the images are being served correctly with the new Content-Disposition header, including checking that images display correctly in the browser.
12. Logging: Add logging to capture the Content-Disposition header and the filename being returned, as well as any errors that occur during image processing.
13. Separation of Concerns: Refactor to separate image processing and response generation into distinct functions for better maintainability.

As part of my research, I'm trying to understand how useful these comments are in real-world development. If you have a moment, I'd be super grateful if you could quickly reply to these two yes/no questions:

1. Does this comment provide suggestions from a dimension you hadn’t considered?

2. Do you find this comment helpful?

Thanks a lot for your time and feedback! And sorry again if this message is a bother.

[jtydhr88]

hi @OrangeDoro, same to #8716, I suggest do not use working/reviewing PR for your study, it may be confuse for later core team reviewer.
Other than these, I suggest you choose draft PRs which put on hold, for example, you could use #8265 and Comfy-Org/ComfyUI_frontend#3976 which contain BE and FE changes, I am the owner of these two PRs

[kevinpaik1]

PR Review Summary

Status: ✅ Approved for Core Team Review

For the Contributor

Thank you for this clean fix to the Content-Disposition headers! Your PR properly addresses issue #8914 by making the headers RFC 6266 compliant. The implementation is minimal and correct - exactly what we want to see.

Technical Summary

• Scope: Updates Content-Disposition headers to include 'inline' directive
• Files Changed: 1 file (+4/-4 lines)
• Build Status: ✅ PASS
• Test Status: ✅ PASS (manual verification)
• Security: ✅ Clean
• Architecture: ✅ Aligned

Review Highlights

Strengths:

• Follows RFC 6266 standard correctly
• Minimal change that solves the specific issue
• Maintains full backward compatibility
• Good documentation with before/after evidence

Key Findings:

• The 'inline' directive is the browser default, so this change explicitly declares existing behavior
• No security implications as filename parameter is already validated
• Performance impact is negligible (7 bytes per response)

Remaining Items: None

Next Steps

This PR is ready for core team review. The core team will conduct their own evaluation and may request additional changes before merge.

For Core Team

Focus Areas: Standard review - RFC compliance verification
Review Complexity: Low - straightforward header format fix

[guill]

This seems like a good and safe fix.

[guill]

It looks like you may need to merge back from main (or rebase) to get the updates that allow you to pass the new Windows Line Endings CI. Apologies for the inconvenience.

[Myestery]

all done @guill

[kevinpaik1]

Thank you for your contribution @Myestery!