[Web-SIG] ANN: Release 0.20.0 of modjy: a WSGI gateway for jython 2.1 and J2EE.

[Phillip J. Eby]

At 12:00 AM 10/4/04 +0100, Alan Kennedy wrote:
>[Phillip J. Eby]
>>(I wonder if perhaps the current mechanism to prevent middleware 
>>bypassing is too heavyweight?)
>
>I'm sort of thinking that it is a little heavyweight. I think that anyone 
>who wants to bypass the middleware will probably have a good reason for 
>doing so. Also, they would probably be very aware that their application 
>would no longer be portable.

Well, the problem isn't portability, nor is it *intending* to bypass 
middleware.  The problem is that you can write a portable program that uses 
bypass APIs for performance when they're available, but then mysteriously 
breaks when you add middleware to the mix, because it's bypassing the 
middleware.


>Also, I would have to add a fair amount of extra code, just to ensure that 
>the extension APIs present the same information as the standard WSGI 
>interface. Which seems unnecessary, given that the WSGI information is 
>already there.

Right.  I think it's a natural first thought to say, "Oh, I'll add an 
extension API so you can get at the original server request", but given the 
purpose of WSGI, at second thought it seems rather pointless.  If the app 
author wanted something non-portable, he'd have written to the server's API 
to begin with.  If it's *extra* information you're providing, just add it 
to environ, as long as it's not information *derived* from other data in 
environ.  If it's derived, offer a function to derive it, rather than data.

If you're providing a special input feature, attach it to the input stream, 
so that if middleware replaces the input stream, it disables the feature 
automatically.  If it's a special output feature, supply an 
iterator-wrapper that can be returned by the application for special 
treatment by the server, or make it an attribute of start_response.

Maybe the above guidelines should be added to the spec.


>More importantly, that extra code would then make it impossible for the 
>application/framework author to get at the original request, which they 
>might conceivably really, really, need .....

For...?


>But I am concerned about the statement in the PEP which says "it is very 
>important that these "safe extension" rules be followed by both 
>server/gateway and middleware developers, in order to avoid a future in 
>which middleware developers are forced to delete any and all extension 
>APIs from environ to ensure that their mediation isn't being bypassed by 
>applications using those extensions!"
>
>I definitely don't want to bring such a future about ....

That is the big issue, yes.  When an app behaves mysteriously when 
middleware is added, the middleware author will get the blame, even though 
the application developer did everything right, and the server author is 
the real culprit.  So, the middleware author will gripe and grumble and add 
code to delete the server's extensions...  in which case there was no point 
in the server author putting them there.