don't know if we should proceed with a ::map<std::string, std::vector<std::string>> structure for headers ..
by the time only the last remains in the mapping.
Spec:
Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.
Note: In practice, the "Set-Cookie" header field ([RFC6265]) often appears multiple times in a response message and does not use the list syntax, violating the above requirements on multiple header fields with the same name. Since it cannot be combined into a single field-value, recipients ought to handle "Set-Cookie" as a special case while processing header fields. (See Appendix A.2.3 of [Kri2001] for details.)
So, maybe we could stay with ::map<std::string, std::string> and attain to the spec: in case of collision, append w/ comma. As we don't really care about cookies this might suffice.
It's common to have something like:
don't know if we should proceed with a
::map<std::string, std::vector<std::string>>
structure for headers ..by the time only the last remains in the mapping.
Spec:
So, maybe we could stay with
::map<std::string, std::string>
and attain to the spec: in case of collision, append w/ comma. As we don't really care about cookies this might suffice.