RFC: A standardized interface between web servers and
applications or frameworks (ala WSGI)
cdsmith at twu.net
Sun Apr 13 21:32:07 EDT 2008
On Sun, 13 Apr 2008 16:06:43 -0700, Adam Langley wrote:
> On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell <johan.tibell at gmail.com>
>> * 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 .
Wait, I'm not sure I agree here. How are headers not just strings? By
assuming that, are we guaranteeing that anything using this interface
cannot respond gracefully to a client that writes malformed headers?
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?
> Likewise, URLs have
> lots of structure that should just be handled in one place 
This I do agree with.
More information about the Libraries