On Sun, 2010-12-26 at 10:42 -0800, Marcel Holtmann wrote: > > > 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. 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: X-Spam-Report: SpamAssassin version 3.3.1 on canuck.infradead.org summary: Content analysis details: (6.3 points) pts rule name description ---- ---------------------- -------------------------------------------------- 1.3 RCVD_IN_RP_RNBL RBL: Relay in RNBL, https://senderscore.org/blacklistlookup/ [89.234.9.153 listed in bl.score.senderscore.com] 0.8 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist [URIs: tmfinsider.ae] 0.8 HTML_IMAGE_RATIO_02 BODY: HTML has a low ratio of text to image area 0.0 HTML_MESSAGE BODY: HTML included in message 1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 1.0 HTML_IMAGE_ONLY_16 BODY: HTML: images with 1200-1600 bytes of words 0.0 MIME_BASE64_BLANKS RAW: Extra blank lines in base64 encoding 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS ... instead of the original version: X-Spam-Report: SpamAssassin version 3.3.1 on canuck.infradead.org summary: Content analysis details: (6.3 points) pts rule name description ---- ---------------------- -------------------------------------------------- 1.3 RCVD_IN_RP_RNBL RBL: Relay in RNBL, https://senderscore.org/blacklistlookup/ [89.234.9.153 listed in bl.score.senderscore.com] 0.8 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist [URIs: tmfinsider.ae] 0.8 HTML_IMAGE_RATIO_02 BODY: HTML has a low ratio of text to image area 0.0 HTML_MESSAGE BODY: HTML included in message 1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 1.0 HTML_IMAGE_ONLY_16 BODY: HTML: images with 1200-1600 bytes of words 0.0 MIME_BASE64_BLANKS RAW: Extra blank lines in base64 encoding 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS 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. -- dwmw2 _______________________________________________ connman mailing list [email protected] http://lists.connman.net/listinfo/connman
