[Web-SIG] Web Container Interface

[Phillip J. Eby]

At 12:58 AM 1/29/04 -0600, Ian Bicking wrote:
>On Jan 28, 2004, at 11:27 PM, Jacob Smullyan wrote:
>>>Obviously some
>>>containers (ack, too many alternative terminologies at this point) will
>>>not be able to finish the request until after control has been returned
>>>from runCGI, but I don't see how that can be helped.
>>
>>It may be true that it can't be helped -- but it isn't obvious to me,
>>yet.  Is there anything about the assumptions of some frameworks that
>>would prevent a file-like object they are writing to from doing some
>>networking when they close it?  I would think that is the business of
>>the container, not the containee.  Or do you mean that the container
>>may be in turn nested in a preexisting environment, not optimized
>>specifically for this sort of containment, to which it delegates its
>>networking responsibilities -- the "run Zope inside WebWare" scenario?
>>That kind of scenario shouldn't be a sticking point, in my view,
>>because it will always be suboptimal.  If you want coexistence of two
>>different application environments, I'd expect to do better nesting
>>them both in one shared container which has limited, specialized
>>functionality than arranging them serially (Zope running inside
>>WebWare running inside SkunkWeb running inside...).  A lower level of
>>compliance, for such "convenience serial containers", would be
>>forgiveable.
>
>I almost took it back, that all containers should be able to do a network 
>response when you close.  But I'm not sure about plain CGI -- the only way 
>to finish a CGI request may be to end the process.

It is, at least with Apache on the Linux platform I tried it on once.  :)


>>My focussing on flush() rather than close() was the wrong emphasis.
>>The reason I made that mistake was that I assumed that the container
>>was not in the business of worrying about http, but that that was the
>>responsibility of an adapter sitting between the application proper
>>and the container (that the container was in no-parsed-header mode, in
>>cgi terms); in that case, the container has no reason not to flush
>>when the client toggles the handle, rather than waiting for him to get
>>off the pot.  Upon reflection, I think the container *should* parse
>>headers by default -- what a bore for every adapter to have to do
>>this.
>
>I think it's implied that the container will parse the headers, since 
>that's what we're all used to from CGI.

Well, it's definitely implied that the headers will be parsed, but not by 
whom.  CGI and FastCGI gateways have the luxury of allowing the upstream 
webserver to do the parsing.  :)


>   This should consist mostly of the Status header, and maybe the Location 
> header.  I've never been clear on the Location header, though -- it's 
> semantics are very unclear to me in the absence of a Status header.

IIRC, it's supposed to imply a Status: 302 header, which is how I've 
implemented in WSGIServer.


>   I think with Apache you get an internal redirect if you give a path 
> without a host name, and an external temporary redirect otherwise.  But 
> in some environments I think it always becomes an external redirect, and 
> relative paths are resolved to absolute paths before being sent to the 
> client.  That might be nice to define.  Or to strongly encourage 
> applications to only use fully qualified redirects, and to always give a 
> Status header unless doing a 200 response.

I think that the latter recommendation would likely be best.  I was really 
hoping to avoid turning the PEP into Yet Another Attempt To Formalize CGI, 
though.  :(


>>However, it would be nice if in runCGI you could set an
>>attribute of output that would tell it whether to parse headers or
>>not; it would seem reasonable to at least aspire to the range of
>>functionality already implemented by CGI :).  But I don't know if
>>Mr. Eby wants his nice abstract output object mucked up with pesky
>>attributes!  (This suggests a T-shirt: "Get your attributes off my
>>object!" -- "attributes" being more polite, if less general, than
>>"members".)
>
>Yes, I suspect he won't like that addition ;)

Not because of the attribute per se, but because gateways couldn't 
guarantee honoring it.  CGI and FastCGI gateways would be powerless to 
*stop* header parsing, for example.

If we had to have something like this, it'd need to be done in such a way 
that a container that couldn't do 'nph' style services would simply refuse 
to boot the service up in the first place, or else make this property known 
to the app at startup.

In general, though, I'm still loath to add properties that have to be 
checked by the service.  For example, I consider the DBAPI spec's inclusion 
of the "paramstyle" property to be broken because it means I can't write 
portable DBAPI code without bypassing the use of parameters!  Thus, this is 
an area where I'd rather see the app say, "I can't live without unparsed 
headers, so don't even bother running me if you can't handle it."

OTOH, I don't believe the unparsed header style is common for most 
apps/frameworks that aren't built into webservers to start with, so I'd 
like to dodge the entire issue if possible.  :)


>It would be nice to better specify what kind of parsing will occur, what 
>headers might be added, which are off limits (to application or to 
>container).  CGI is poorly specified.

Indeed.