Re: WSAPI replacement draft

[LeafStorm <leafstormrush@...>]

On 01/25/2011 12:24 PM, Stuart P. Bentley wrote:
> ?Okay, going through the proposal with a more finely-toothed comb right
> now as I'm writing [my fork](http://gist.github.com/794881), I have more
> in-depth feedback:
>
> Version:
> ======================
> My fork uses 0.1.0 as a version number. Even if the draft is supposed to
> be completely informal, putting a version number you would ever expect
> to see in production on a draft you would not is a bad idea. [It
> shouldn't say it's ready until it
> is.](http://testtrack4.com/wiki/Pardon_Our_Dust)

Good idea as for the 0.x version number, but I explicitly had the 
version number as a *number* (as opposed to a string) for a reason - 
namely, it's much easier to do comparisons with numbers than with 
strings (you can explicitly do a "greater than" or "less than," and you 
can use math.floor to get the minor version), and also I don't think 
that there would really be "patch level" changes to the spec - just 
minor changes and breaks-backwards-compatibility changes.

> Things that are ambiguous:
> ======================
> - According to the Response Body section (which doesn't list strings as
> a response type, even though that's what's used in the example in the
> "Interface" section):
>
> "When this is returned from a request handler, each value is sent to the
> client, in sequence, without being transformed in any way."
>
> Does this mean that the strings will be concatenated to form the
> response body, and does "without being transformed in any way" preclude
> the CRLF line ending normalization required for HTTP?

Concatenated to form the request body. What I meant by "without being 
transformed in any way" was, "no separators are applied." Also, as far 
as the CRLF issue, I'm pretty sure that only applies to the headers. 
(After all, what would happen if you transferred a binary file that just 
happened to have a "10" byte in it?)

> Things my fork doesn't keep:
> =======================
> environ.serverhost
> ------------------------
> It's redundant with headers.host (which, as Rack's documentation says,
> is a better place to look).

The original purpose of this was for being able to quickly determine 
subdomains. Of course, it's probably easier just to have the base domain 
be handled by the application's configuration if necessary, especially 
when you consider virtual hosting.

> environ.approot
> ---------------------
> If a middleware function is going to change "prefix", why can't it just
> define "approot" itself if its apps need it?

Yeah, the distinction between "approot" and "prefix" is a bit unclear 
(especially since my plans for the server I'm writing have it literally 
calling into a LASI handler as soon as the request is parsed.)

Both this and environ.serverhost were based on the "Super Secret WSGI 
Replacement." The author, Armin Ronacher, has a lot of experience with 
WSGI, so I assumed he had a specific use case for it.

> environ.input
> ------------------
> Replaced with a straight "body" string that contains the POST body,
> since the only reason to make this a stream is to accommodate CGI.

Nope. For example: assume someone uploads a 4.2 MB photo to your photo 
hosting site. You don't want the whole thing in memory at once 
(especially if your site is particularly high-traffic) - much easier 
just to stream it to a file in nice, manageable 4K blocks.

--
Regards, Matthew "LeafStorm" Frazier
http://leafstorm.us/