[Web-SIG] ANN: Release 0.20.0 of modjy: a WSGI gateway for
jython 2.1 and J2EE.
Phillip J. Eby
pje at telecommunity.com
Mon Oct 4 04:38:47 CEST 2004
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
>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
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 .....
>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.
More information about the Web-SIG