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 current map[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 the ReadMIMEHeader 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 current ReadMIMEHeader API, but it also makes available a new function (i.e.: ReadMIMEOrderedHeader) that delivers the order information.
I hope this could help others.
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.