I think that makes sense in a high level HTTP library. For a low level HTTP library I think it a design mistake, much simpler is much better. Less is more. I've used the above serialiser design on a number of occasions now, it's very efficient, composable, and flexible. It *does* push understanding of HTTP onto the end user, but then if the end user doesn't understand HTTP, they wouldn't be able to use a low level library anyway.
If BEAST is accepted, is there any reason why such an even--lower-level library could not (or should not) be written (and also accepted)?
That's a great question. It could be that I am over egging the importance of there being a lower layer independent of networking implementation. But then my past HTTP implementations have tended to go over some really weird non-socket transport layers, so I'm going on what I know. Hence I delay my review until others have given theirs. I know that's a cop out, but it's also recognition that my experience of "normal" HTTP is limited, and I could be making unreasonable demands. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/