Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Fixed #18029 -- Removed leftover mod_python files forgotten in r17835.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@17849 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit d2e273e2958316ac8045971d7bfc790596e8f6cf 1 parent 37c8bc8
@claudep claudep authored
View
56 django/contrib/auth/handlers/modpython.py
@@ -1,56 +0,0 @@
-from mod_python import apache
-import os
-
-def authenhandler(req, **kwargs):
- """
- Authentication handler that checks against Django's auth database.
- """
-
- # mod_python fakes the environ, and thus doesn't process SetEnv. This fixes
- # that so that the following import works
- os.environ.update(req.subprocess_env)
-
- # apache 2.2 requires a call to req.get_basic_auth_pw() before
- # req.user and friends are available.
- req.get_basic_auth_pw()
-
- # check for PythonOptions
- _str_to_bool = lambda s: s.lower() in ('1', 'true', 'on', 'yes')
-
- options = req.get_options()
- permission_name = options.get('DjangoPermissionName', None)
- staff_only = _str_to_bool(options.get('DjangoRequireStaffStatus', "on"))
- superuser_only = _str_to_bool(options.get('DjangoRequireSuperuserStatus', "off"))
- settings_module = options.get('DJANGO_SETTINGS_MODULE', None)
- if settings_module:
- os.environ['DJANGO_SETTINGS_MODULE'] = settings_module
-
- from django.contrib.auth.models import User
- from django import db
- db.reset_queries()
-
- # check that the username is valid
- kwargs = {'username': req.user, 'is_active': True}
- if staff_only:
- kwargs['is_staff'] = True
- if superuser_only:
- kwargs['is_superuser'] = True
- try:
- try:
- user = User.objects.get(**kwargs)
- except User.DoesNotExist:
- return apache.HTTP_UNAUTHORIZED
-
- # check the password and any permission given
- if user.check_password(req.get_basic_auth_pw()):
- if permission_name:
- if user.has_perm(permission_name):
- return apache.OK
- else:
- return apache.HTTP_UNAUTHORIZED
- else:
- return apache.OK
- else:
- return apache.HTTP_UNAUTHORIZED
- finally:
- db.connection.close()
View
180 django/core/handlers/modpython.py
@@ -1,180 +0,0 @@
-import os
-import sys
-from warnings import warn
-
-from django import http
-from django.core import signals
-from django.core.handlers.base import BaseHandler
-from django.core.urlresolvers import set_script_prefix
-from django.utils import datastructures
-from django.utils.encoding import force_unicode, iri_to_uri
-from django.utils.log import getLogger
-
-logger = getLogger('django.request')
-
-class ModPythonRequest(http.HttpRequest):
- def __init__(self, req):
- self._req = req
- # FIXME: This isn't ideal. The request URI may be encoded (it's
- # non-normalized) slightly differently to the "real" SCRIPT_NAME
- # and PATH_INFO values. This causes problems when we compute path_info,
- # below. For now, don't use script names that will be subject to
- # encoding/decoding.
- self.path = force_unicode(req.uri)
- root = req.get_options().get('django.root', '')
- self.django_root = root
- # req.path_info isn't necessarily computed correctly in all
- # circumstances (it's out of mod_python's control a bit), so we use
- # req.uri and some string manipulations to get the right value.
- if root and req.uri.startswith(root):
- self.path_info = force_unicode(req.uri[len(root):])
- else:
- self.path_info = self.path
- if not self.path_info:
- # Django prefers empty paths to be '/', rather than '', to give us
- # a common start character for URL patterns. So this is a little
- # naughty, but also pretty harmless.
- self.path_info = u'/'
- self._post_parse_error = False
- self._stream = self._req
- self._read_started = False
-
- def get_full_path(self):
- # RFC 3986 requires self._req.args to be in the ASCII range, but this
- # doesn't always happen, so rather than crash, we defensively encode it.
- return '%s%s' % (self.path, self._req.args and ('?' + iri_to_uri(self._req.args)) or '')
-
- def _is_secure(self):
- try:
- return self._req.is_https()
- except AttributeError:
- # mod_python < 3.2.10 doesn't have req.is_https().
- return self._req.subprocess_env.get('HTTPS', '').lower() in ('on', '1')
-
- def _get_request(self):
- if not hasattr(self, '_request'):
- self._request = datastructures.MergeDict(self.POST, self.GET)
- return self._request
-
- def _get_get(self):
- if not hasattr(self, '_get'):
- self._get = http.QueryDict(self._req.args, encoding=self._encoding)
- return self._get
-
- def _set_get(self, get):
- self._get = get
-
- def _get_post(self):
- if not hasattr(self, '_post'):
- self._load_post_and_files()
- return self._post
-
- def _set_post(self, post):
- self._post = post
-
- def _get_cookies(self):
- if not hasattr(self, '_cookies'):
- self._cookies = http.parse_cookie(self._req.headers_in.get('cookie', ''))
- return self._cookies
-
- def _set_cookies(self, cookies):
- self._cookies = cookies
-
- def _get_files(self):
- if not hasattr(self, '_files'):
- self._load_post_and_files()
- return self._files
-
- def _get_meta(self):
- "Lazy loader that returns self.META dictionary"
- if not hasattr(self, '_meta'):
- self._meta = {
- 'AUTH_TYPE': self._req.ap_auth_type,
- 'CONTENT_LENGTH': self._req.headers_in.get('content-length', 0),
- 'CONTENT_TYPE': self._req.headers_in.get('content-type'),
- 'GATEWAY_INTERFACE': 'CGI/1.1',
- 'PATH_INFO': self.path_info,
- 'PATH_TRANSLATED': None, # Not supported
- 'QUERY_STRING': self._req.args,
- 'REMOTE_ADDR': self._req.connection.remote_ip,
- 'REMOTE_HOST': None, # DNS lookups not supported
- 'REMOTE_IDENT': self._req.connection.remote_logname,
- 'REMOTE_USER': self._req.user,
- 'REQUEST_METHOD': self._req.method,
- 'SCRIPT_NAME': self.django_root,
- 'SERVER_NAME': self._req.server.server_hostname,
- 'SERVER_PORT': self._req.connection.local_addr[1],
- 'SERVER_PROTOCOL': self._req.protocol,
- 'SERVER_SOFTWARE': 'mod_python'
- }
- for key, value in self._req.headers_in.items():
- key = 'HTTP_' + key.upper().replace('-', '_')
- self._meta[key] = value
- return self._meta
-
- def _get_method(self):
- return self.META['REQUEST_METHOD'].upper()
-
- GET = property(_get_get, _set_get)
- POST = property(_get_post, _set_post)
- COOKIES = property(_get_cookies, _set_cookies)
- FILES = property(_get_files)
- META = property(_get_meta)
- REQUEST = property(_get_request)
- method = property(_get_method)
-
-class ModPythonHandler(BaseHandler):
- request_class = ModPythonRequest
-
- def __call__(self, req):
- warn(('The mod_python handler is deprecated; use a WSGI or FastCGI server instead.'),
- DeprecationWarning)
-
- # mod_python fakes the environ, and thus doesn't process SetEnv. This fixes that
- os.environ.update(req.subprocess_env)
-
- # now that the environ works we can see the correct settings, so imports
- # that use settings now can work
- from django.conf import settings
-
- # if we need to set up middleware, now that settings works we can do it now.
- if self._request_middleware is None:
- self.load_middleware()
-
- set_script_prefix(req.get_options().get('django.root', ''))
- signals.request_started.send(sender=self.__class__)
- try:
- try:
- request = self.request_class(req)
- except UnicodeDecodeError:
- logger.warning('Bad Request (UnicodeDecodeError)',
- exc_info=sys.exc_info(),
- extra={
- 'status_code': 400,
- }
- )
- response = http.HttpResponseBadRequest()
- else:
- response = self.get_response(request)
- finally:
- signals.request_finished.send(sender=self.__class__)
-
- # Convert our custom HttpResponse object back into the mod_python req.
- req.content_type = response['Content-Type']
- for key, value in response.items():
- if key != 'content-type':
- req.headers_out[str(key)] = str(value)
- for c in response.cookies.values():
- req.headers_out.add('Set-Cookie', c.output(header=''))
- req.status = response.status_code
- try:
- for chunk in response:
- req.write(chunk)
- finally:
- response.close()
-
- return 0 # mod_python.apache.OK
-
-def handler(req):
- # mod_python hooks into this function.
- return ModPythonHandler()(req)
View
25 django/core/handlers/profiler-hotshot.py
@@ -1,25 +0,0 @@
-import hotshot
-import os
-import time
-
-from django.core.handlers.modpython import ModPythonHandler
-
-PROFILE_DATA_DIR = "/var/log/cmsprofile"
-
-def handler(req):
- '''
- Handler that uses hotshot to store profile data.
-
- Stores profile data in PROFILE_DATA_DIR. Since hotshot has no way (that I
- know of) to append profile data to a single file, each request gets its own
- profile. The file names are in the format <url>.<n>.prof where <url> is
- the request path with "/" replaced by ".", and <n> is a timestamp with
- microseconds to prevent overwriting files.
-
- Use the gather_profile_stats.py script to gather these individual request
- profiles into aggregated profiles by request path.
- '''
- profname = "%s.%.3f.prof" % (req.uri.strip("/").replace('/', '.'), time.time())
- profname = os.path.join(PROFILE_DATA_DIR, profname)
- prof = hotshot.Profile(profname)
- return prof.runcall(ModPythonHandler(), req)
View
415 docs/howto/deployment/modpython.txt
@@ -1,415 +0,0 @@
-============================================
-How to use Django with Apache and mod_python
-============================================
-
-.. warning::
-
- Support for mod_python has been deprecated, and will be removed in
- Django 1.5. If you are configuring a new deployment, you are
- strongly encouraged to consider using :doc:`mod_wsgi
- </howto/deployment/wsgi/modwsgi>` or any of the other :doc:`supported
- servers </howto/deployment/index>`.
-
-.. highlight:: apache
-
-The `mod_python`_ module for Apache_ can be used to deploy Django to a
-production server, although it has been mostly superseded by the simpler
-:doc:`mod_wsgi deployment option </howto/deployment/wsgi/modwsgi>`.
-
-mod_python is similar to (and inspired by) `mod_perl`_ : It embeds Python within
-Apache and loads Python code into memory when the server starts. Code stays in
-memory throughout the life of an Apache process, which leads to significant
-performance gains over other server arrangements.
-
-Django requires Apache 2.x and mod_python 3.x, and you should use Apache's
-`prefork MPM`_, as opposed to the `worker MPM`_.
-
-.. seealso::
-
- * Apache is a big, complex animal, and this document only scratches the
- surface of what Apache can do. If you need more advanced information about
- Apache, there's no better source than `Apache's own official
- documentation`_
-
- * You may also be interested in :doc:`How to use Django with FastCGI, SCGI,
- or AJP </howto/deployment/fastcgi>`.
-
-.. _Apache: http://httpd.apache.org/
-.. _mod_python: http://www.modpython.org/
-.. _mod_perl: http://perl.apache.org/
-.. _prefork MPM: http://httpd.apache.org/docs/2.2/mod/prefork.html
-.. _worker MPM: http://httpd.apache.org/docs/2.2/mod/worker.html
-.. _apache's own official documentation: http://httpd.apache.org/docs/
-
-Basic configuration
-===================
-
-To configure Django with mod_python, first make sure you have Apache installed,
-with the mod_python module activated.
-
-Then edit your ``httpd.conf`` file and add the following::
-
- <Location "/mysite/">
- SetHandler python-program
- PythonHandler django.core.handlers.modpython
- SetEnv DJANGO_SETTINGS_MODULE mysite.settings
- PythonOption django.root /mysite
- PythonDebug On
- </Location>
-
-...and replace ``mysite.settings`` with the Python import path to your Django
-project's settings file.
-
-This tells Apache: "Use mod_python for any URL at or under '/mysite/', using the
-Django mod_python handler." It passes the value of :ref:`DJANGO_SETTINGS_MODULE
-<django-settings-module>` so mod_python knows which settings to use.
-
-Because mod_python does not know we are serving this site from underneath the
-``/mysite/`` prefix, this value needs to be passed through to the mod_python
-handler in Django, via the ``PythonOption django.root ...`` line. The value set
-on that line (the last item) should match the string given in the ``<Location
-...>`` directive. The effect of this is that Django will automatically strip the
-``/mysite`` string from the front of any URLs before matching them against your
-URLconf patterns. If you later move your site to live under ``/mysite2``, you
-will not have to change anything except the ``django.root`` option in the config
-file.
-
-When using ``django.root`` you should make sure that what's left, after the
-prefix has been removed, begins with a slash. Your URLconf patterns that are
-expecting an initial slash will then work correctly. In the above example,
-since we want to send things like ``/mysite/admin/`` to ``/admin/``, we need
-to remove the string ``/mysite`` from the beginning, so that is the
-``django.root`` value. It would be an error to use ``/mysite/`` (with a
-trailing slash) in this case.
-
-Note that we're using the ``<Location>`` directive, not the ``<Directory>``
-directive. The latter is used for pointing at places on your filesystem,
-whereas ``<Location>`` points at places in the URL structure of a Web site.
-``<Directory>`` would be meaningless here.
-
-Also, if your Django project is not on the default ``PYTHONPATH`` for your
-computer, you'll have to tell mod_python where your project can be found:
-
-.. parsed-literal::
-
- <Location "/mysite/">
- SetHandler python-program
- PythonHandler django.core.handlers.modpython
- SetEnv DJANGO_SETTINGS_MODULE mysite.settings
- PythonOption django.root /mysite
- PythonDebug On
- **PythonPath "['/path/to/project'] + sys.path"**
- </Location>
-
-The value you use for ``PythonPath`` should include the parent directories of
-all the modules you are going to import in your application. It should also
-include the parent directory of the :ref:`DJANGO_SETTINGS_MODULE
-<django-settings-module>` location. This is exactly the same situation as
-setting the Python path for interactive usage. Whenever you try to import
-something, Python will run through all the directories in ``sys.path`` in turn,
-from first to last, and try to import from each directory until one succeeds.
-
-Make sure that your Python source files' permissions are set such that the
-Apache user (usually named ``apache`` or ``httpd`` on most systems) will have
-read access to the files.
-
-An example might make this clearer. Suppose you have some applications under
-``/usr/local/django-apps/`` (for example, ``/usr/local/django-apps/weblog/`` and
-so forth), your settings file is at ``/var/www/mysite/settings.py`` and you have
-specified :ref:`DJANGO_SETTINGS_MODULE <django-settings-module>` as in the above
-example. In this case, you would need to write your ``PythonPath`` directive
-as::
-
- PythonPath "['/usr/local/django-apps/', '/var/www'] + sys.path"
-
-With this path, ``import weblog`` and ``import mysite.settings`` will both
-work. If you had ``import blogroll`` in your code somewhere and ``blogroll``
-lived under the ``weblog/`` directory, you would *also* need to add
-``/usr/local/django-apps/weblog/`` to your ``PythonPath``. Remember: the
-**parent directories** of anything you import directly must be on the Python
-path.
-
-.. note::
-
- If you're using Windows, we still recommended that you use forward
- slashes in the pathnames, even though Windows normally uses the backslash
- character as its native separator. Apache knows how to convert from the
- forward slash format to the native format, so this approach is portable and
- easier to read. (It avoids tricky problems with having to double-escape
- backslashes.)
-
- This is valid even on a Windows system::
-
- PythonPath "['c:/path/to/project'] + sys.path"
-
-You can also add directives such as ``PythonAutoReload Off`` for performance.
-See the `mod_python documentation`_ for a full list of options.
-
-Note that you should set ``PythonDebug Off`` on a production server. If you
-leave ``PythonDebug On``, your users would see ugly (and revealing) Python
-tracebacks if something goes wrong within mod_python.
-
-Restart Apache, and any request to ``/mysite/`` or below will be served by
-Django. Note that Django's URLconfs won't trim the "/mysite/" -- they get passed
-the full URL.
-
-When deploying Django sites on mod_python, you'll need to restart Apache each
-time you make changes to your Python code.
-
-.. _mod_python documentation: http://modpython.org/live/current/doc-html/directives.html
-
-Multiple Django installations on the same Apache
-================================================
-
-It's entirely possible to run multiple Django installations on the same Apache
-instance. Just use ``VirtualHost`` for that, like so::
-
- NameVirtualHost *
-
- <VirtualHost *>
- ServerName www.example.com
- # ...
- SetEnv DJANGO_SETTINGS_MODULE mysite.settings
- </VirtualHost>
-
- <VirtualHost *>
- ServerName www2.example.com
- # ...
- SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
- </VirtualHost>
-
-If you need to put two Django installations within the same ``VirtualHost``
-(or in different ``VirtualHost`` blocks that share the same server name),
-you'll need to take a special precaution to ensure mod_python's cache doesn't
-mess things up. Use the ``PythonInterpreter`` directive to give different
-``<Location>`` directives separate interpreters::
-
- <VirtualHost *>
- ServerName www.example.com
- # ...
- <Location "/something">
- SetEnv DJANGO_SETTINGS_MODULE mysite.settings
- PythonInterpreter mysite
- </Location>
-
- <Location "/otherthing">
- SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
- PythonInterpreter othersite
- </Location>
- </VirtualHost>
-
-The values of ``PythonInterpreter`` don't really matter, as long as they're
-different between the two ``Location`` blocks.
-
-Running a development server with mod_python
-============================================
-
-If you use mod_python for your development server, you can avoid the hassle of
-having to restart the server each time you make code changes. Just set
-``MaxRequestsPerChild 1`` in your ``httpd.conf`` file to force Apache to reload
-everything for each request. But don't do that on a production server, or we'll
-revoke your Django privileges.
-
-If you're the type of programmer who debugs using scattered ``print``
-statements, note that output to ``stdout`` will not appear in the Apache
-log and can even `cause response errors`_.
-
-.. _cause response errors: http://blog.dscpl.com.au/2009/04/wsgi-and-printing-to-standard-output.html
-
-If you have the need to print debugging information in a mod_python setup, you
-have a few options. You can print to ``stderr`` explicitly, like so::
-
- print >> sys.stderr, 'debug text'
- sys.stderr.flush()
-
-(note that ``stderr`` is buffered, so calling ``flush`` is necessary if you wish
-debugging information to be displayed promptly.)
-
-A more compact approach is to use an assertion::
-
- assert False, 'debug text'
-
-Another alternative is to add debugging information to the template of your page.
-
-Serving media files
-===================
-
-Django doesn't serve media files itself; it leaves that job to whichever Web
-server you choose.
-
-We recommend using a separate Web server -- i.e., one that's not also running
-Django -- for serving media. Here are some good choices:
-
-* lighttpd_
-* Nginx_
-* TUX_
-* A stripped-down version of Apache_
-* Cherokee_
-
-If, however, you have no option but to serve media or static files on the
-same Apache ``VirtualHost`` as Django, here's how you can turn off mod_python
-for a particular part of the site::
-
- <Location "/media">
- SetHandler None
- </Location>
-
-Just change ``Location`` to the root URL of your media files. You can also use
-``<LocationMatch>`` to match a regular expression.
-
-This example sets up Django at the site root but explicitly disables Django
-for the ``media`` and ``static`` subdirectories and any URL that ends with
-``.jpg``, ``.gif`` or ``.png``::
-
- <Location "/">
- SetHandler python-program
- PythonHandler django.core.handlers.modpython
- SetEnv DJANGO_SETTINGS_MODULE mysite.settings
- </Location>
-
- <Location "/media">
- SetHandler None
- </Location>
-
- <Location "/static">
- SetHandler None
- </Location>
-
- <LocationMatch "\.(jpg|gif|png)$">
- SetHandler None
- </LocationMatch>
-
-.. _lighttpd: http://www.lighttpd.net/
-.. _Nginx: http://wiki.nginx.org/Main
-.. _TUX: http://en.wikipedia.org/wiki/TUX_web_server
-.. _Apache: http://httpd.apache.org/
-.. _Cherokee: http://www.cherokee-project.com/
-
-Serving the admin files
-=======================
-
-Note that the Django development server automagically serves the static files
-of the admin app, but this is not the case when you use any other server
-arrangement. You're responsible for setting up Apache, or whichever media
-server you're using, to serve the admin files.
-
-The admin files live in (:file:`django/contrib/admin/static/admin`) of the
-Django distribution.
-
-We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle the
-admin files (this means using the :djadmin:`collectstatic` management command
-to collect the static files in :setting:`STATIC_ROOT`, and then configuring
-your Web server to serve :setting:`STATIC_ROOT` at :setting:`STATIC_URL`), but
-here are two other approaches:
-
-1. Create a symbolic link to the admin static files from within your
- document root.
-
-2. Or, copy the admin static files so that they live within your Apache
- document root.
-
-Using "eggs" with mod_python
-============================
-
-If you installed Django from a Python egg_ or are using eggs in your Django
-project, some extra configuration is required. Create an extra file in your
-project (or somewhere else) that contains something like the following:
-
-.. code-block:: python
-
- import os
- os.environ['PYTHON_EGG_CACHE'] = '/some/directory'
-
-Here, ``/some/directory`` is a directory that the Apache Web server process can
-write to. It will be used as the location for any unpacking of code the eggs
-need to do.
-
-Then you have to tell mod_python to import this file before doing anything
-else. This is done using the PythonImport_ directive to mod_python. You need
-to ensure that you have specified the ``PythonInterpreter`` directive to
-mod_python as described above__ (you need to do this even if you aren't
-serving multiple installations in this case). Then add the ``PythonImport``
-line in the main server configuration (i.e., outside the ``Location`` or
-``VirtualHost`` sections). For example::
-
- PythonInterpreter my_django
- PythonImport /path/to/my/project/file.py my_django
-
-Note that you can use an absolute path here (or a normal dotted import path),
-as described in the `mod_python manual`_. We use an absolute path in the
-above example because if any Python path modifications are required to access
-your project, they will not have been done at the time the ``PythonImport``
-line is processed.
-
-.. _Egg: http://peak.telecommunity.com/DevCenter/PythonEggs
-.. _PythonImport: http://www.modpython.org/live/current/doc-html/dir-other-pimp.html
-.. _mod_python manual: PythonImport_
-__ `Multiple Django installations on the same Apache`_
-
-Error handling
-==============
-
-When you use Apache/mod_python, errors will be caught by Django -- in other
-words, they won't propagate to the Apache level and won't appear in the Apache
-``error_log``.
-
-The exception for this is if something is really wonky in your Django setup. In
-that case, you'll see an "Internal Server Error" page in your browser and the
-full Python traceback in your Apache ``error_log`` file. The ``error_log``
-traceback is spread over multiple lines. (Yes, this is ugly and rather hard to
-read, but it's how mod_python does things.)
-
-If you get a segmentation fault
-===============================
-
-If Apache causes a segmentation fault, there are two probable causes, neither
-of which has to do with Django itself.
-
-1. It may be because your Python code is importing the "pyexpat" module,
- which may conflict with the version embedded in Apache. For full
- information, see `Expat Causing Apache Crash`_.
-
-2. It may be because you're running mod_python and mod_php in the same
- Apache instance, with MySQL as your database backend. In some cases,
- this causes a known mod_python issue due to version conflicts in PHP and
- the Python MySQL backend. There's full information in the
- `mod_python FAQ entry`_.
-
-If you continue to have problems setting up mod_python, a good thing to do is
-get a barebones mod_python site working, without the Django framework. This is
-an easy way to isolate mod_python-specific problems. `Getting mod_python Working`_
-details this procedure.
-
-The next step should be to edit your test code and add an import of any
-Django-specific code you're using -- your views, your models, your URLconf,
-your RSS configuration, etc. Put these imports in your test handler function
-and access your test URL in a browser. If this causes a crash, you've confirmed
-it's the importing of Django code that causes the problem. Gradually reduce the
-set of imports until it stops crashing, so as to find the specific module that
-causes the problem. Drop down further into modules and look into their imports,
-as necessary.
-
-.. _Expat Causing Apache Crash: http://www.dscpl.com.au/wiki/ModPython/Articles/ExpatCausingApacheCrash
-.. _mod_python FAQ entry: http://modpython.org/FAQ/faqw.py?req=show&file=faq02.013.htp
-.. _Getting mod_python Working: http://www.dscpl.com.au/wiki/ModPython/Articles/GettingModPythonWorking
-
-If you get a UnicodeEncodeError
-===============================
-
-If you're taking advantage of the internationalization features of Django (see
-:doc:`/topics/i18n/index`) and you intend to allow users to upload files, you must
-ensure that the environment used to start Apache is configured to accept
-non-ASCII file names. If your environment is not correctly configured, you
-will trigger ``UnicodeEncodeError`` exceptions when calling functions like
-``os.path()`` on filenames that contain non-ASCII characters.
-
-To avoid these problems, the environment used to start Apache should contain
-settings analogous to the following::
-
- export LANG='en_US.UTF-8'
- export LC_ALL='en_US.UTF-8'
-
-Consult the documentation for your operating system for the appropriate syntax
-and location to put these configuration items; ``/etc/apache2/envvars`` is a
-common location on Unix platforms. Once you have added these statements
-to your environment, restart Apache.
Please sign in to comment.
Something went wrong with that request. Please try again.