On Mon, 14 Apr 2008 13:32:07 Chris Smith wrote:

On Sun, 13 Apr 2008 16:06:43 -0700, Adam Langley wrote:

...

On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell

wrote:

...

* Using a different set of data types would work better.

Give that this is Haskell, I'd suggest more types ;)

HTTP headers aren't just strings and, at the risk of tooting my own horn, I'll point to the Headers structure in [1].

Wait, I'm not sure I agree here. How are headers not just strings?

Headers, at least their values, aren't strings. The specification says so. I think headers should be represented by something more specific than a string.

By assuming that, are we guaranteeing that anything using this interface cannot respond gracefully to a client that writes malformed headers?

Having explicit types for headers doesn't preclude trying to handle messages with malformed headers. Soldiering on in the face of malformed messages as a general strategy is pretty dubious in my opinion. In the specific cases where you've determined it is necessary you want to be able to register a work-around parser for that section of the message, and be able to tell that it has been used. A decent framework can supply a catalogue of commonly required work-arounds.

Another perspective: there is unnecessary variation there in how interfaces are represented. If I'm looking for a header, and I know its name as a string, how do I look for it? Well, apparently it's either a named field (if it's known to the interface) or in the "other" section (if not). So I write a gigantic case analysis? But then suppose the interface is updated later to include some headers that popped up unofficially but then are standardized in a future RFC. (This is not too odd; lots of REST web services invent new headers every day, many of which do things that make sense outside of the particular application.) Does old code that handled these headers stop working, just because it was looking in the "other" section, but now needs to check a field dedicated to that header?

I don't like the idea of having a fixed enumeration of methods or headers. You need to be able to define new methods and headers at will, and ideally have the usage of headers constrained to valid contexts. This suggests to me type classes that establish a 'can occur in' relationship between request/response, method and a given general/request/response/entity header. By importing new method or header data type, appropriate type class instances and registering an appropriate message parser extension you can mix and match which headers and methods you support. GET and HEAD are the only ones that MUST be supported after all. Daniel