The mod_wsgi.ssl_is_https and mod_wsgi.ssl_var_lookup hook functions in WSGI environ dictionary were only being made available in auth callbacks and not in the main WSGI application, because they will not work in the latter if mod_wsgi daemon mode were being used. They only existed for the auth callbacks because the environment variables aren't available at that point.
So, for a WSGI application, you should only use the environment variable approach for it to be able to work for both embedded mode and daemon mode. I agree that it looks like reference counting is wrong if using Python 3 and/or using an invalid value as argument to ssl_var_lookup function. Should have been okay for normal use case under Python 2.X though. Does that mean you are using Python 3? Anyway, will create a ticket for fixing it. Not sure when will get to doing that though. Graham On 29 March 2013 08:49, Wade C <[email protected]> wrote: > Ah, thanks for that. I had set it previously, but then forgot to add > .wsgi when I changed the handlers for mod_wsgi to use that extension. My > ssl configuration was restricted to certain filename extensions. > > I had expected to get it by calling environ['mod_ssl.var_lookup'] based on > a document I'd read elsewhere, but then discovered that the implementation > has been commented out in the source, and so that's why I was wondering > about adding support. > > Anyway, if you're interested, here's a patch to fix the crash in the > ssl_var_lookup code. There was some incorrect reference counting around > PyArg_ParseTuple(args, "O:ssl_var_lookup", &item). > > Thanks again for the tip on StdEnvVars. > > Wade > > > On Wednesday, 27 March 2013 22:08:25 UTC-7, Graham Dumpleton wrote: > >> As far as I can tell, this is all handled by Apache. So long as you have: >> >> SSLOptions StdEnvVars >> >> then the variable 'SSL_TLS_SNI' should be passed in the WSGI environ. >> >> That is the only thing that I can see would be different from the >> perspective of mod_wsgi. >> >> What more are you expecting? >> >> Graham >> >> >> >> On 28 March 2013 15:10, Wade C <[email protected]> wrote: >> >>> I was wondering if this is planned (ref http://en.wikipedia.org/wiki/** >>> Server_Name_Indication<http://en.wikipedia.org/wiki/Server_Name_Indication>). >>> If so, is there any documentation for how this information can be retrieved >>> by the wsgi application? >>> >>> If not, would you be willing to accept a patch to support this? >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "modwsgi" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to modwsgi+u...@**googlegroups.com. >>> To post to this group, send email to [email protected]. >>> >>> Visit this group at >>> http://groups.google.com/**group/modwsgi?hl=en<http://groups.google.com/group/modwsgi?hl=en> >>> . >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>> . >>> >>> >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/modwsgi?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
