Fixers — Werkzeug 0.9.4 documentation

### Navigation

- index
- modules |
- next |
- previous |
- Werkzeug 0.9.4 documentation »
- Contributed Modules »

# Fixers

New in version 0.5.

This module includes various helpers that fix bugs in web servers. They may be necessary for some versions of a buggy web server but not others. We try to stay updated with the status of the bugs as good as possible but you have to make sure whether they fix the problem you encounter.

If you notice bugs in webservers not fixed in this module consider contributing a patch.

class `werkzeug.contrib.fixers.` `CGIRootFix`(app, app_root='/')

  Wrap the application in this middleware if you are using FastCGI or CGI and you have problems with your app root being set to the cgi script’s path instead of the path users are going to visit

  Changed in version 0.9: Added app_root parameter and renamed from LighttpdCGIRootFix.

  Parameters: | app – the WSGI application app_root – Defaulting to `'/'`, you can set this to something else if your app is mounted somewhere else.

class `werkzeug.contrib.fixers.` `PathInfoFromRequestUriFix`(app)

  On windows environment variables are limited to the system charset which makes it impossible to store the PATH_INFO variable in the environment without loss of information on some systems.

  This is for example a problem for CGI scripts on a Windows Apache.

  This fixer works by recreating the PATH_INFO from REQUEST_URI, REQUEST_URL, or UNENCODED_URL (whatever is available). Thus the fix can only be applied if the webserver supports either of these variables.

  Parameters: | app – the WSGI application

class `werkzeug.contrib.fixers.` `ProxyFix`(app, num_proxies=1)

  This middleware can be applied to add HTTP proxy support to an application that was not designed with HTTP proxies in mind. It sets REMOTE_ADDR, HTTP_HOST from X-Forwarded headers.

  If you have more than one proxy server in front of your app, set num_proxies accordingly.

  Do not use this middleware in non-proxy setups for security reasons.

  The original values of REMOTE_ADDR and HTTP_HOST are stored in the WSGI environment as werkzeug.proxy_fix.orig_remote_addr and werkzeug.proxy_fix.orig_http_host.

  Parameters: | app – the WSGI application num_proxies – the number of proxy servers in front of the app.

  `get_remote_addr`(forwarded_for)

    Selects the new remote addr from the given list of ips in X-Forwarded-For. By default it picks the one that the num_proxies proxy server provides. Before 0.9 it would always pick the first.

    New in version 0.8.

class `werkzeug.contrib.fixers.` `HeaderRewriterFix`(app, remove_headers=None, add_headers=None)

  This middleware can remove response headers and add others. This is for example useful to remove the Date header from responses if you are using a server that adds that header, no matter if it’s present or not or to add X-Powered-By headers:

      app = HeaderRewriterFix(app, remove_headers=['Date'],
                              add_headers=[('X-Powered-By', 'WSGI')])

  Parameters: | app – the WSGI application remove_headers – a sequence of header keys that should be removed. add_headers – a sequence of `(key, value)` tuples that should be added.

class `werkzeug.contrib.fixers.` `InternetExplorerFix`(app, fix_vary=True, fix_attach=True)

  This middleware fixes a couple of bugs with Microsoft Internet Explorer. Currently the following fixes are applied:

  - removing of Vary headers for unsupported mimetypes which causes troubles with caching. Can be disabled by passing `fix_vary=False` to the constructor. see: http://support.microsoft.com/kb/824847/en-us
  - removes offending headers to work around caching bugs in Internet Explorer if Content-Disposition is set. Can be disabled by passing `fix_attach=False` to the constructor.

  If it does not detect affected Internet Explorer versions it won’t touch the request / response.