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 <[EMAIL PROTECTED]>
> >
> > 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
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
