Implements a new http header system, with one class per header

[serialseb]

This is all about making http compliance easier.

• Refactor the existing headers to adopt a one class per header model.
• Change the way headers are written, with a mapping in each hosting environment between header and writing action. This is important for redirecting certain header values to host-specific APIs (content-length etc).
• Create classes for all http headers defined in RFC2616

[serialseb]

Preparing for release

[lee.m.henson@…]

I might take a stab at this over the weekend. Seb, can you go into a little more detail on what you mean by:

"Change the way headers are written, with a mapping in each hosting environment between header and writing action. This is important for redirecting certain header values to host-specific APIs (content-length etc)."

[serialseb]

There's the initial code in  http://svn.caffeine-it.com/openrasta/branches/httpheader/

Idea is to have proper classes for each http header, with transparent casting between the header and its value where appropriate (ContentLength? and long for example), so we don't break API compat.

I've also added the type of header for most of those classes, so we can start showing the entity headers on IHttpEntity, the request ones on IRequest, etc.

We also need to solve the "problem" of parsing and rendering the headers for the ones that are allowed to be present several times and can be combined / recombined. Most headers should always be combined, except for those that cause an issue (such as the Set-Cookie one).

To write them down, we need some support API for the WriteHeaders?() method, as a lot of hosting environments *cough*asp.net*cough* require that you call the proper property on their response object rather than simply write the header.

And on a side note, there's some work to do to abstract away the header parsing from the multipart codec into its own component, so it can be reused / abstracted away for components that would parse http requests themselves. I'm thinking of parsing this away as a separate codec for the message/http media type. It'd remove a lot of the complexity in the current multipart codec, and would need to work nicely with the new http headers.

So it's mostly non-trivial changes :)

Seb