You have multiple conflicting configurations. CGI. WSGI script file by extension. And mounting using Alias. Can't do them all at once.
On 10/11/2014, at 2:16 PM, Anthony Dycks <[email protected]> wrote: > # Added .py for Python To AddHandler Below (Required for cgi Module) > AddHandler cgi-script .cgi .pl .py .asp Remove .py extension from this. This can cause CGI to take precedence. AddHandler cgi-script .cgi .pl .asp > http-mod_wsgi.conf file lines ... Created the following httpd-wsgi.conf file: > > #Alias /wsgi-scripts/ "C:/xampp/htdocs/wsgi/scripts/" # make sure all Alias > come before WSGIScriptAlias > WSGIScriptReloading On You do not need the WSGIScriptReloading directive, that is the default. > <Directory "C:/xampp/htdocs/wsgi/scripts"> > AddHandler wsgi-script .wsgi .py Get rid off this AddHandler directive for .py, it is not needed. > Options +ExecCGI Get rid of this Options line, it is not needed. > Order allow,deny > Allow from all > </Directory> > <IfModule wsgi_module> > WSGIScriptAlias /wsgi-scripts/ "C:/xampp/htdocs/wsgi/scripts/" This will result in every file in that directory, regardless of extension now being handled as a WSGI script file for an application. Each would run in a separate sub interpreter within the server processes. Having them all run separately could result in a lot of memory use if you have a lot. I don't know what you are trying to do but the more usual way is to use a Python web framework and rather than expose a whole directory of WSGi script files, have one only within all the handlers being specified in the way the framework is used. WSGIScriptAlias /wsgi-app "C:/xampp/htdocs/wsgi/scripts/wsgi.py" > Sample helloworld.wsgi in same directory as pyinfo.py program: > > def application(environ, start_response): > status = '200 OK' > output = 'Hello Python World!' > response_headers = [('Content-type', 'text/plain'), ('Content-Length', > str(len(output)))] > start_response(status, response_headers) > return [output] > > Test URL: http://localhost:8081/UCLA/LearnPython/helloworld.wsgi Wrong URL. The URL would have been: http://localhost:8081/wsgi-scripts/helloworld.wsgi > Also tried the same program with a helloworld.py but received the 500 HTML > error > > Apache Error Log: > > [Sun Nov 09 09:00:01.395777 2014] [cgi:error] [pid 7978] [client ::1:42475] > End of script output before headers: helloworld.py Which means the CGI configuration took precedence and mod_wsgi wasn't being used. > Have attempted a similar configuration on my CentOS Linux 6.5 box with > similar results. In the linux environment I followed the Apache Friends link > above and built my Python and mod_wsgi internally from the source tar gunzip > files. Any reason you didn't follow the mod_wsgi docs themselves rather than using some other site? :-) If you have access to Linux, which is a much better option than Windows, maybe you should use simpler mod_wsgi-express. So on Linux try: https://pypi.python.org/pypi/mod_wsgi Graham > On Saturday, November 8, 2014 7:32:37 PM UTC-8, Graham Dumpleton wrote: > The way of installing mod_wsgi using a setup.py file using 'python' directly, > or 'pip', will not be back ported to mod_wsgi 3.X as there is no point when > there is a newer version of mod_wsgi available. This style of installation > will likely not make its way to Windows either, or not soon. Even if it does, > mod_wsgi-express would not be available on Windows. > > If your concern is the lack of mod_wsgi version 4.X for Windows then I > wouldn't be overly concerned as you aren't missing out on much by only having > mod_wsgi 3.5 binaries being available for Windows at this point because the > majority of changes in 4.X relate to mod_wsgi daemon mode and > mod_wsgi-express and so aren't relevant to Windows. > > As to what is stopping there being binaries available for Windows for > mod_wsgi 4.X, it is purely the lack of updated makefiles for the Windows > platforms. I don't run a Windows machine any more and can't verify any > changes I might make to the makefiles. The mod_wsgi code itself still should > support Windows, although with no ability to compile it on Windows myself, > there is a greater chance I could be breaking things for Windows as I > refactor the code and improve it. That is not intentional though. > > The current makefiles for the Windows platform are currently in: > > * https://github.com/GrahamDumpleton/mod_wsgi/tree/develop/win32 > > The following needs to happen for these to be brought up to date. > > * Compensate for the fact that the makefiles are now in a sub directory and > not the parent directory of the source code. Any path names to source code > files need to be changed. > * Compensate for the fact that the source code files themselves are now > located in the src/server subdirectory and instead of there being only one > source code file, there are now many. All these source code files have to be > enumerated in the makefiles and any extra build targets created appropriately. > * Versions of the makefiles added for Python 3.3 and 3.4 (that for Python 3.1 > can be removed). The paths for the required Microsoft C compiler for those > Python versions need to be set appropriately. > * Versions of the makefiles added for Apache 2.4. > > As I don't have Windows, what would be great is someone who could come up > with the changes. Even better, provide a Python script which can be used to > automatically generate the makefiles. This would be preferred as I am > continually splitting out the code into more files to make it easier to work > on. It would be good if I had a way of regenerating the makefiles based on > what is found in the src/server directory, rather than me having to update > them by hand. > > So what is the underlying reason as to why you asked your original question. > > Graham > > On 09/11/2014, at 7:31 AM, Anthony Dycks <[email protected]> wrote: > >> Some additional Version background on my system environment: >> >> Platform: Windows 7 Pro 32-bit >> Python Installation: >> Version 2.7.6 32 Bit >> (Default Install for Multiple User; User installed had Admin privileges) >> LAMP Stack: XAMPP v1.8.2 32-bit >> Apache Server: v2.4.7 >> mod_wsgi Install: Binary: mod_wsgi‑3.5.ap24.win32‑py2.7.zip >> >> >> On Saturday, November 8, 2014 10:10:24 AM UTC-8, Anthony Dycks wrote: >> From reading the Python PyPi Index descriptionon for mod_wsgi v4.3, I >> understand that mod_wsgi v4.3 can be installed within the Python >> Interpreter. Can the latest release of mod_wsgi v3.5 be installed within >> the Python Interpreter as well? >> >> If I install mod_wsgi within the Python Interpreter do I need to remove the >> mod_wsgi3.5.so - private module reference from the Apache httpd.conf file to >> prevent versioning and environment issues? >> >> Thanks! >> >> -- >> 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. >> For more options, visit https://groups.google.com/d/optout. > > > -- > 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. > For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
