RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)

[Chris Smith]

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>
> 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?  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 [2]

This I do agree with.

-- 
Chris Smith