https://issues.apache.org/bugzilla/show_bug.cgi?id=50581
--- Comment #7 from Graham Dumpleton <[email protected]> 2011-01-14 23:34:00 EST --- OP is wrong on a few accounts. First off, under WSGI scripts the correct way of identifying whether HTTPS was used is to check the wsgi.url_scheme variable. The value of HTTPS cannot be relied upon and could be missing depending on the WSGI hosting environment being used even though HTTPS may be used. Their probe output even showed the correct value to check: 'wsgi.url_scheme': 'https' Second thing wrong is that the environ they printed out was a WSGI per request environment and not process wide environment variables from os.environ. That WSGI per request environment isn't the same as what you would see for a CGI script where process environment variables are used and so you cant use CGI as the basis for what is in it. FWIW, the WSGI specification even gives an example for a CGI/WSGI bridge which is tolerant of HTTPS being 'On' or '1' as historically there seems to have been hosting systems where 'On' may not have been used: if environ.get('HTTPS', 'off') in ('on', '1'): environ['wsgi.url_scheme'] = 'https' else: environ['wsgi.url_scheme'] = 'http' A value of '1' for HTTPS was also potentially used in non WSGI hosting systems for Python in the past as some Python web frameworks were hardwired to look for HTTPS being '1' rather than 'On' and also weren't updated to use wsgi.url_scheme instead. It is to accommodate those Python web frameworks that '1' in particular was used rather than 'On' for what was a variable being passed in WSGI environment and nothing to do with CGI or Apache. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
