-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
proposal: net/textproto: ReadMIMEHeader to return the original order of the parsed headers #50868
Comments
We can't change the signature of the existing Please tell us more about the use case where the order matters. Thanks. |
It's true - this would essentially require a separate implementation. A fork in a third-party package might be the best approach. |
This proposal has been added to the active column of the proposals project |
Based on the discussion above, this proposal seems like a likely decline. |
@ianlancetaylor one of the use cases for preserving the order in which headers appear on an email is detecting the use of email templates (botnets use this extensively), among other things. It would be nice to avoid the fork in order to carry all the improvements/optimizations made to the standard library over time, but I guess this modification could also be maintained in the fork, updating as new Golang versions make changes (tagging the fork with the Golang version used as baseline, etc.) |
For what it's worth, this function does not change very often at all. Divergence should not be a problem. |
No change in consensus, so declined. |
The current implementation of the net/textproto's Reader.ReadMIMEHeader returns a
map[string][]string
that, when it is iterated to consume map's values, the order of the creation of those items in the map is lost.I came across a use case where the original order of the headers being parsed must be preserved.
In order to make this work, I was able to port part of such code to a custom method that I would like to contribute to the community.
Despite the actual work I've done, I see 2 alternatives to make this change:
Modify
ReadMIMEHeader
output to return a new struct that preserves the order of the headers, alongside the currentmap[string][]string
instance. Such a new struct will also provide a function to iterate over the map following the order of the headers (this is basically my current implementation, but it breaks theReadMIMEHeader
API)Provide a new functionality on the same
Reader
struct that takes into consideration the order of the headers. So then the Reader still provides the currentReadMIMEHeader
API, but it also makes available a new function (i.e.:ReadMIMEOrderedHeader
) that delivers the order information.I hope this could help others.
The text was updated successfully, but these errors were encountered: