Hi Dave, > > > > And please use g_hash_table_replace() instead of insert. See the GLib > > > > documentation for details or test it by yourself. There is a > > > > different. > > > > > > Hrm. Can't you have repeated headers? If you replace, wouldn't you throw > > > away the previous one when you get the second? > > > > What I read from the HTTP specification, we can not. > > Set-Cookie: is a counter-example to that. > > > > Does nobody ever care about ordering of headers either? > > > > I also read that the order doesn't matter. Only the initial HTTP > > response has to be first. For the others it does not matter. > > > > Please correct me here if I read this wrong. Using a hash table would be > > pretty idea idea if this is not true ;) > > You can have multiple headers with the same name, which has defined > semantics. And in *that* case, order does matter. From RFC2616 ยง4.2: > > The order in which header fields with differing field names are > received is not significant. However, it is "good practice" to send > general-header fields first, followed by request-header or response- > header fields, and ending with the entity-header fields. > > 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. > > > But even if the RFC says the ordering doesn't matter for other headers, > that still doesn't mean you should deliberately shuffle the results just > because you can.
so what I read here is that in case we find a header a second time, we need to append its details to the first header we found with that name. That should be to hard. > Evolution does the same kind of thing, mangling whitespace because the > RFC says it doesn't matter and showing me an X-Spam-Report: header as: <snip> > It's a quality of implementation issue. We should abide by the principle > of minimal munging and preserve the input data as much as possible. And > that includes ordering. I am all for keeping whitespace as they are. However the hash table is more for convenient and fast access to a particular header. It is not about mangling the header values. Using a list would be rather stupid here. Regards Marcel _______________________________________________ connman mailing list [email protected] http://lists.connman.net/listinfo/connman
