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][]stringthat, 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
ReadMIMEHeaderoutput to return a new struct that preserves the order of the headers, alongside the currentmap[string][]stringinstance. 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 theReadMIMEHeaderAPI)Provide a new functionality on the same
Readerstruct that takes into consideration the order of the headers. So then the Reader still provides the currentReadMIMEHeaderAPI, 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: