Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aws s3 type inference should supply a charset for text/ mime types #8574

Closed
2 tasks done
couling opened this issue Mar 12, 2024 · 4 comments
Closed
2 tasks done

aws s3 type inference should supply a charset for text/ mime types #8574

couling opened this issue Mar 12, 2024 · 4 comments
Assignees
Labels
duplicate This issue is a duplicate. feature-request A feature should be added or improved. p2 This is a standard priority issue s3

Comments

@couling
Copy link

couling commented Mar 12, 2024

Describe the feature

Some commands under aws s3 will set a mime type while uploading files. This is based on a type inference system. When the type inference system results in a type starting with text/ it should try to append ; charst=<charset> or at least offer the option to do so.

There's a number of ways this might be inferred and I'm agnostic as to which:

  • Use environment variables provided by the system
  • Add an explicit switch to set the charset
  • Try to guess the charset based on content

Use Case

Where an S3 backed cloud-front website may serve plain text files, there is no other way to indicate the charset of the file. As it stands, the current behaviour forces clients to assume US-ASKII or ISO-8859-1 and this is very rarely right.

RFC 2854 Section 6

The use of an explicit charset parameter is strongly recommended. While [MIME] specifies "The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII."

As it stands the only way to achieve this is to completely bypass the type inference system which means users are left to build their own inference system.

By allowing the client set set a charset for either all text/* types or otherwise specifically set charset for specific mime types such as text/plain, these can then be set correctly in S3 and thus be correct when retrieved through cloud-front.

Proposed Solution

Add an option to set the charset explicitly for text types, or alternatively add an option to infer the charset from the current console's environment variables. This would append ; charset=... to each text mime type. Eg: text/plain; charset=utf-8.

Other Information

No response

Acknowledgements

  • I may be able to implement this feature request
  • This feature might incur a breaking change

CLI version used

2.15.24

Environment details (OS name and version, etc.)

Macos / Linux

@couling couling added feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged. labels Mar 12, 2024
@tim-finnigan tim-finnigan self-assigned this May 16, 2024
@tim-finnigan tim-finnigan added the investigating This issue is being investigated and/or work is in progress to resolve the issue. label May 16, 2024
@tim-finnigan
Copy link
Contributor

Thanks for the feature request and your patience here. It looks like this closely overlaps with #1346, so we may want to consider consolidating these for tracking going forward. Are there any specific distinctions you want to highlight between these two feature requests?

@tim-finnigan tim-finnigan added s3 response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. p2 This is a standard priority issue and removed investigating This issue is being investigated and/or work is in progress to resolve the issue. needs-triage This issue or PR still needs to be triaged. labels May 16, 2024
@tim-finnigan tim-finnigan removed their assignment May 16, 2024
@couling
Copy link
Author

couling commented May 20, 2024

No I think this is largely a duplicate. I'd draw attention to the suggestion of using the console's default such as the LANG environment variable under linux. But beyond that they are the same suggestion. Pity the earlier one is 9 years old with seemingly little progress.

@github-actions github-actions bot removed the response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. label May 20, 2024
@tim-finnigan tim-finnigan self-assigned this May 21, 2024
@tim-finnigan
Copy link
Contributor

Thanks for confirming — I'll go ahead and close this as a duplicate. Please consider adding a 👍 to the related issue and leaving a comment there if you want to add any other context.

@tim-finnigan tim-finnigan closed this as not planned Won't fix, can't repro, duplicate, stale May 21, 2024
@tim-finnigan tim-finnigan added the duplicate This issue is a duplicate. label May 21, 2024
Copy link

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate This issue is a duplicate. feature-request A feature should be added or improved. p2 This is a standard priority issue s3
Projects
None yet
Development

No branches or pull requests

2 participants