On Tue, 2010-12-28 at 08:59 -0800, Marcel Holtmann wrote: > 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.
We don't necessarily need to do that. Semantically, that's how it should be handled. But we aren't interpreting this stuff; just transporting it. > > 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. I'm not talking about whitespace specifically; that was just an example. I'm drawing attention to the general principle that we should preserve the input data as faithfully as possible and not lose information. So unless there's a good reason to merge 'duplicate' headers, or to lose the ordering information, I would suggest that we preserve the original input. You generally don't have *that* many headers in an HTTP response. Fetching a specific header from a list instead of from a hash table really isn't going to have serious performance implications. Assuming, that is, that you intend this to be a fairly generic library. If you are planning to use it *only* within ConnMan and maybe PACrunner for certain limited uses, then of course it's fair enough to mangle as you wish. -- dwmw2 _______________________________________________ connman mailing list [email protected] http://lists.connman.net/listinfo/connman
