This document is for an old version of Python that is no longer supported. You should upgrade, and read the Python documentation for the current stable release.

# `wsgiref` — Utilidades WSGI e implementación de referencia

La Interfaz de Pasarela del Servidor Web, o Web Server Gateway Interface en inglés (WSGI), es una interfaz estándar entre el servidor web y aplicaciones web escritas en Python. Con una interfaz estándar es más sencillo usar una aplicación que soporte WSGI con diferentes servidores web.

Sólo los autores de servidores y frameworks web necesitan conocer cada detalle y caso límite del diseño WSGI. No es necesario conocer cada detalle de WSGI sólo para instalar o escribir una aplicación web usando un framework existente.

`wsgiref` es una implementación de referencia de la especificación WSGI que se puede usar para añadir soporte WSGI a un servidor o framework web. Este módulo provee utilidades para manipular las variables de entorno WSGI y las cabeceras de respuesta, clases base para implementar servidores WSGI, un servidor HTTP de demostración que sirve aplicaciones WSGI, y una herramienta de validación que comprueba la compatibilidad de servidores y aplicaciones WSGI en base a la especificación PEP 3333.

Vea wsgi.readthedocs.io para más información sobre WSGI, así como enlaces a tutoriales y otros recursos.

## `wsgiref.util` – Utilidades de entorno WSGI

Este módulo ofrece una variedad de funciones útiles para trabajar con entornos WSGI. Un entorno WSGI es un diccionario que contiene variables de la petición HTTP, descrito en PEP 3333. Todas las funciones que aceptan un parámetro environ esperan un diccionario compatible con WSGI. Por favor, consulte la especificación detallada en PEP 3333.

`wsgiref.util.``guess_scheme`(environ)

  Retorna una deducción del valor para `wsgi.url_scheme` que debería ser «http» o «https», buscando la variable de entorno `HTTPS` en el diccionario environ. El valor de retorno es una cadena.

  Esta función es útil al crear un gateway que envuelve CGI o un protocolo similar como FastCGI. Habitualmente, los servidores que ofrecen estos protocolos incluyen una variable `HTTPS` con el valor «1», «yes», o «on» cuando reciben una petición vía SSL. Así, esta función retorna «https» si encuentra ese valor, o «http», en caso contrario.

`wsgiref.util.``request_uri`(environ, include_query=True)

  Retorna la URI completa de la petición, opcionalmente la cadena de consulta, usando el algoritmo encontrado en la sección «URL Reconstruction» de PEP 3333. Si include_query es falso, la cadena de consulta no se incluye en la URI resultante.

`wsgiref.util.``application_uri`(environ)

  Similar a `request_uri()` excepto que se ignoran las variables `PATH_INFO` y `QUERY_STRING`. El resultado es la URI base del objeto de aplicación indicado en la petición.

`wsgiref.util.``shift_path_info`(environ)

  Desplaza un solo nombre de `PATH_INFO` a `SCRIPT_NAME` y retorna el nombre. Se modifica el diccionario environ, por lo que se deberá usar una copia si se quiere mantener `PATH_INFO` o `SCRIPT_NAME` intactos.

  Si no quedan segmentos en `PATH_INFO`, retornará `None`.

  Habitualmente, esta rutina se usa para procesar cada porción de la ruta del URI de la petición, por ejemplo, para usar la ruta como una serie de claves en un diccionario. Esta rutina modifica el entorno pasado para permitir invocar otra aplicación WSGI que esté localizada en la URI objetivo. Por ejemplo, si hay una aplicación WSGI en `/foo`, y la ruta es `/foo/bar/baz`, y la aplicación WSGI en `/foo` llama a `shift_path_info()`, recibirá la cadena «bar», y se actualizará el entorno para pasarlo a una aplicación WSGI en `/foo/bar`. Es decir, `SCRIPT_NAME` cambiará de `/foo` a `/foo/bar` y `PATH_INFO` cambiará de `/bar/baz` a `/baz`.

  Cuando `PATH_INFO` es únicamente «/», esta rutina retornará una cadena vacía y añadirá una barra final a `SCRIPT_NAME`, incluso cuando normalmente los segmentos de ruta vacíos se ignoran y `SCRIPT_NAME` no acaba con una barra. Este comportamiento es intencional, para asegurar que una aplicación puede diferenciar entre URIs que acaban en `/x` de las que acaban en `/x/` cuando usan esta rutina para atravesar objetos.

`wsgiref.util.``setup_testing_defaults`(environ)

  Actualiza environ con valores por defecto triviales con propósito de prueba.

  Esta rutina añade varios parámetros requeridos por WSGI, incluyendo `HTTP_POST`, `SERVER_NAME`, `SERVER_PORT`, `REQUEST_METHOD`, `SCRIPT_NAME`, `PATH_INFO`, y todas las variables `wsgi.*` definidas en PEP 3333. Sólo ofrece valores por defecto y no reemplaza ningún valor existente en esas variables.

  Esta rutina pretende facilitar la preparación de entornos ficticios para pruebas unitarias de servidores y aplicaciones WSGI. NO debería usarse en servidores y aplicaciones WSGI reales, ya que los valores son ficticios!

  Ejemplo de uso:

      from wsgiref.util import setup_testing_defaults
      from wsgiref.simple_server import make_server

      # A relatively simple WSGI application. It's going to print out the
      # environment dictionary after being updated by setup_testing_defaults
      def simple_app(environ, start_response):
          setup_testing_defaults(environ)

          status = '200 OK'
          headers = [('Content-type', 'text/plain; charset=utf-8')]

          start_response(status, headers)

          ret = [("%s: %s\n" % (key, value)).encode("utf-8")
                 for key, value in environ.items()]
          return ret

      with make_server('', 8000, simple_app) as httpd:
          print("Serving on port 8000...")
          httpd.serve_forever()

Además de las funciones de entorno previas, el módulo `wsgiref.util` también ofrece las siguientes utilidades varias:

`wsgiref.util.``is_hop_by_hop`(header_name)

  Retorna `True` si “header_name” es una cabecera «Hop-by-Hop» HTTP/1.1, como se define en RFC 2616.

class `wsgiref.util.``FileWrapper`(filelike, blksize=8192)

  Un wrapper para convertir un objeto archivo en un iterator. Los objetos resultantes soportan los estilos de iteración `__getitem__()` y `__iter__()`, por compatibilidad con Python 2.1 y Jython. A medida que se itera sobre el objeto, el parámetro opcional blksize se pasará repetidamente al método `read()` del objeto archivo para obtener cadenas de bytes para entregar. Cuando `read()` retorna una cadena de bytes vacía, la iteración finalizará y no se podrá reiniciar.

  Si filelike tiene un método `close()`, el objeto retornado también tendrá un método `close()` que llamará al método `close()` del objeto archivo subyacente.

  Ejemplo de uso:

      from io import StringIO
      from wsgiref.util import FileWrapper

      # We're using a StringIO-buffer for as the file-like object
      filelike = StringIO("This is an example file-like object"*10)
      wrapper = FileWrapper(filelike, blksize=5)

      for chunk in wrapper:
          print(chunk)

  Obsoleto desde la versión 3.8: El soporte de `sequence protocol` es obsoleto.

## `wsgiref.headers` – Herramientas para cabeceras de respuesta WSGI

Este módulo ofrece una sola clase, `Headers`, para la manipulación de cabeceras de respuesta WSGI usando un interfaz de mapa.

class `wsgiref.headers.``Headers`([headers])

  Crea un objeto con interfaz de mapa envolviendo headers, que debe ser una lista de tuplas nombre/valor de las cabeceras, como se describe en PEP 3333. El valor por defecto de headers es una lista vacía.

  Los objetos `Headers` soportan las operaciones de mapa habituales incluyendo `__getitem__()`, `get()`, `__setitem__()`, `setdefault()`, `__delitem__()` y `__contains__()`. Para cada uno de esos métodos, la clave es el nombre de la cabecera, sin distinción entre mayúsculas y minúsculas, y el valor es el primer valor asociado con el nombre de la cabecera. Establecer una cabecera borra cualquier valor previamente existente y añade un nuevo valor al final de la lista de cabeceras. En general, el orden de las cabeceras existentes se mantiene, con las nuevas cabeceras añadidas al final de la lista de cabeceras.

  A diferencia de un diccionario, los objetos `Headers` no lanzan un error cuando se intenta obtener o eliminar una clave que no está en la lista de cabeceras subyacente. Al intentar obtener una clave inexistente simplemente se retornará `None`, mientras que el intento de eliminación de una cabecera inexistente simplemente no tendrá ningún efecto.

  Los objetos `Headers` también soportan los métodos `keys()`, `values()`, y `items()`. Las listas retornadas por `keys()` y `items()` pueden incluir la misma clave más de una vez si se trata de una cabecera de valor múltiple. La `len()` de un objeto `Headers` es la misma que la longitud de sus `items()`, que es la misma que la longitud de la lista de cabeceras envuelta. De hecho, el método `items()` simplemente retorna una copia de la lista de cabeceras.

  La llamada `bytes()` sobre un objeto `Headers` retorna una cadena de bytes formateada y lista para su transmisión como cabeceras de respuesta HTTP. Cada cabecera se ubica en una línea con su valor separado por dos puntos y un espacio. Cada línea finaliza con un retorno de carro y un salto de línea, y la cadena de bytes finaliza con una línea en blanco.

  Además de la interfaz de mapa y las funcionalidades de formateado, los objetos `Headers` también ofrecen los siguientes métodos para consultar y añadir cabeceras con múltiples valores, y para añadir cabeceras con parámetros MIME:

  `get_all`(name)

    Retorna una lista de todos los valores para la cabecera indicada.

    La lista retornada tendrá los valores ordenados según la lista de cabeceras original o según se hayan añadido a esta instancia, y podrá contener duplicados. Cualquier campo eliminado y añadido de nuevo estará al final de la lista. Si no existen campos con el nombre indicado, retornará una lista vacía.

  `add_header`(name, value, **_params)

    Añade una cabecera, posiblemente de valor múltiple, con los parámetros MIME opcionales especificados vía argumentos por palabra clave.

    name es el nombre de la cabecera a añadir. Se pueden usar argumentos por palabra clave para establecer parámetros MIME para la cabecera. Cada parámetro debe ser una cadena o `None`. Todos los guiones bajos en los nombres de parámetros se convierten en guiones, dado que los guiones son inválidos en identificadores Python y muchos parámetros MIME incluyen guiones. Si el valor del parámetro es una cadena, se añade a los parámetros del valor de la cabecera con la forma `nombre=valor`. Si es `None`, sólo se añade el nombre del parámetro, para reflejar parámetros MIME sin valor. Ejemplo de uso:

        h.add_header('content-disposition', 'attachment', filename='bud.gif')

    El código anterior añadirá una cabecera como la siguiente:

        Content-Disposition: attachment; filename="bud.gif"

  Distinto en la versión 3.5: El parámetro headers es opcional.

## `wsgiref.simple_server`– Un servidor HTTP WSGI simple

Este módulo implementa un servidor HTTP simple, basado en `http.server`, que sirve aplicaciones WSGI. Cada instancia del servidor sirve una aplicación WSGI simple en una máquina y puerto dados. Si se quiere servir múltiples aplicaciones en una misma máquina y puerto, se deberá crear una aplicación WSGI que analiza `PATH_INFO` para seleccionar qué aplicación invocar para cada petición. Por ejemplo, usando la función `shift_path_info()` de `wsgiref.util`.

`wsgiref.simple_server.``make_server`(host, port, app, server_class=WSGIServer, handler_class=WSGIRequestHandler)

  Crea un nuevo servidor WSGI que sirve en host y port, aceptando conexiones para app. El valor de retorno es una instancia de server_class y procesará peticiones usando handler_class. app debe ser un objeto aplicación WSGI, como se define en PEP 3333.

  Ejemplo de uso:

      from wsgiref.simple_server import make_server, demo_app

      with make_server('', 8000, demo_app) as httpd:
          print("Serving HTTP on port 8000...")

          # Respond to requests until process is killed
          httpd.serve_forever()

          # Alternative: serve one request, then exit
          httpd.handle_request()

`wsgiref.simple_server.``demo_app`(environ, start_response)

  Esta función es una pequeña pero completa aplicación WSGI que retorna una página de texto con el mensaje «Hello world!» y una lista de pares clave/valor obtenida del parámetro environ. Es útil para verificar que un servidor WSGI, como `wsgiref.simple_server`, es capaz de ejecutar una aplicación WSGI simple correctamente.

class `wsgiref.simple_server.``WSGIServer`(server_address, RequestHandlerClass)

  Crea una instancia de `WSGIServer`. server_address debe ser una tupla `(máquina,puerto)` y RequestHandlerClass debe ser la subclase de `http.server.BaseHTTPRequestHandler` que se usará para procesar peticiones.

  Normalmente, no es necesario invocar este constructor, ya que la función `make_server()` puede gestionar todos los detalles.

  `WSGIServer` es una subclase de `http.server.HTTPServer`, por lo que todos sus métodos, como `serve_forever()` y `handle_request()`, están disponibles. `WSGIServer` también ofrece los siguientes métodos específicos de WSGI:

  `set_app`(application)

    Establece el invocable application como la aplicación WSGI que recibirá las peticiones.

  `get_app`()

    Retorna la aplicación invocable actual.

  Habitualmente, sin embargo, no es necesario usar estos métodos adicionales, ya que `set_app()` se llama desde `make_server()` y `get_app()` existe sobretodo para el beneficio de instancias del gestor de peticiones.

class `wsgiref.simple_server.``WSGIRequestHandler`(request, client_address, server)

  Crea un gestor HTTP para la request indicada (es decir un socket), client_address (una tupla ``(máquina,puerto)``), y *server (una instancia `WSGIServer`).

  No es necesario crear instancias de esta clase directamente. Se crean automáticamente bajo demanda por objetos `WSGIServer`. Sin embargo, se pueden crear subclases de esta clase y proveerlas como handler_class a la función `make_server()`. Algunos métodos posiblemente relevantes para sobreescribir en estas subclases:

  `get_environ`()

    Retorna un diccionario con el entorno WSGI para una petición. La implementación por defecto copia el contenido del diccionario atributo `base_environ` del objeto `WSGIserver` y añade varias cabeceras derivadas de la petición HTTP. Cada llamada a este método debe retornar un nuevo diccionario con todas las variables de entorno CGI relevante especificadas en PEP 3333.

  `get_stderr`()

    Retorna el objeto que debe usarse como el flujo de `wsgi.errors`. La implementación por defecto retorna simplemente `sys.stderr`.

  `handle`()

    Procesa la petición HTTP. La implementación por defecto crea una instancia gestora usando una clase `wsgiref.handlers` para implementar la interfaz de aplicación WSGI real.

## `wsgiref.validate` — Verificador de compatibilidad WSGI

Al crear nuevos objetos aplicación WSGI, frameworks, servidores, o middleware, puede ser útil validar la compatibilidad del nuevo código usando `wsgiref.validate`. Este módulo ofrece una función que crea objetos de aplicación WSGI que validan las comunicaciones entre un servidor o gateway WSGI y un objeto de aplicación WSGI, para comprobar la compatibilidad del protocolo en ambos lados.

Hay que observar que esta utilidad no garantiza compatibilidad completa con PEP 3333. La ausencia de errores usando este módulo no implica que no existan errores. Sin embargo, si este módulo produce errores, implica que o el servidor o la aplicación no son 100% compatibles.

Este módulo se basa en el módulo `paste.lint` de la librería Python Paste de Ian Bicking.

`wsgiref.validate.``validator`(application)

  Envuelve application y retorna un nuevo objeto de aplicación WSGI. La aplicación retornada reenviará todas las peticiones a la application original y comprobará que tanto la application como el servidor que la llama son compatibles con la especificación WSGI y con RFC 2616.

  Cualquier incompatibilidad detectada provocará el lanzamiento de un `AssertionError`. Nótese que, sin embargo, cómo se gestionan estos errores depende del servidor. Por ejemplo, `wsgiref.simple_server` y otros servidores basados en `wsgiref.handlers`, que no sobreescriben los métodos de gestión de errores para hacer otras cosas, simplemente escribirán un mensaje de que el error ha ocurrido y volcarán la traza de error en `sys.stderr` o algún otro flujo de errores.

  Este wrapper puede también generar salidas usando el módulo `warnings` para señalar comportamientos que son cuestionables pero que no están realmente prohibidos por PEP 3333. A no ser que se suprima esta salida usando opciones de línea de comandos de Python o la API de `warnings`, cualquier aviso se escribirá en `sys.stderr`, en lugar de en `wsgi.errors`, aunque sean el mismo objeto.

  Ejemplo de uso:

      from wsgiref.validate import validator
      from wsgiref.simple_server import make_server

      # Our callable object which is intentionally not compliant to the
      # standard, so the validator is going to break
      def simple_app(environ, start_response):
          status = '200 OK'  # HTTP Status
          headers = [('Content-type', 'text/plain')]  # HTTP Headers
          start_response(status, headers)

          # This is going to break because we need to return a list, and
          # the validator is going to inform us
          return b"Hello World"

      # This is the application wrapped in a validator
      validator_app = validator(simple_app)

      with make_server('', 8000, validator_app) as httpd:
          print("Listening on port 8000....")
          httpd.serve_forever()

## `wsgiref.handlers` – Clases base servidor/gateway

Este módulo ofrece clases gestoras base para implementar servidores y gateways WSGI. Estas clases base gestionan la mayoría del trabajo de comunicarse con una aplicación WSGI, siempre que se les dé un entorno CGI, junto con una entrada, una salida, y un flujo de errores.

class `wsgiref.handlers.``CGIHandler`

  Invocación basada en CGI vía `sys.stdin`, `sys.stdout`, `sys.stderr` y `os.environ`. Esto es útil cuando se quiere ejecutar una aplicación WSGI como un script CGI. Simplemente es necesario invocar `CGIHandler().run(app)`, donde `app` es el objeto de aplicación WSGI que se quiere invocar.

  Esta clase es una subclase de `BaseCGIHandler` que establece `wsgi.run_once` a cierto, `wsgi.multithread` a falso, y `wsgi.multiprocess` a cierto, y siempre usa `sys` y `os` para obtener los flujos y entorno CGI necesarios.

class `wsgiref.handlers.``IISCGIHandler`

  Una alternativa especializada a `CGIHandler`, para usar al desplegar en servidores web Microsoft IIS, sin establecer la opción de configuración `allowPathInfo` (IIS>=7) o la meta-base `allowPathInfoForScriptMappings` (IIS<7).

  Por defecto, IIS entrega `PATH_INFO` que duplica `SCRIPT_NAME` al principio, causando problemas con aplicaciones WSGI que implementan enrutamiento. Este gestor elimina las partes duplicadas de la ruta.

  IIS se puede configurar para pasar el `PATH_INFO` correcto, pero esto causa otro error donde `PATH_TRANSLATED` es incorrecto. Afortunadamente, esta variable rara vez se usa y no está garantizada por WSGI. Sin embargo, en IIS<7, la configuración solo se puede realizar en un nivel de vhost, lo que afecta a todas las demás asignaciones de scripts, muchas de las cuales se rompen cuando se exponen al error `PATH_TRANSLATED`. Por esta razón, IIS<7 casi nunca se implementa con la solución (incluso IIS7 rara vez lo usa porque todavía no tiene una interfaz de usuario).

  No hay forma de que el código CGI detecte cuándo la opción está activada, por lo que se ofrece una clase gestora separada. Se usa de la misma forma que `CGIHandler`, p.e. llamando a `IISCGIHandler().run(app)`, donde `app` es el objeto aplicación WSGI que se desea invocar.

  Nuevo en la versión 3.2.

class `wsgiref.handlers.``BaseCGIHandler`(stdin, stdout, stderr, environ, multithread=True, multiprocess=False)

  Similar a `CGIHandler`, pero en lugar de usar los módulos `sys` y `os`, el entorno CGI y los flujos de E/S se especifican explícitamente. Los valores multithread y multiprocess se pasan a las aplicaciones ejecutadas por la instancia de gestión como `wsgi.multithread` y `wsgi.multiprocess`.

  Esta clase es una subclase de `SimpleHandler` para usarse con servidores HTTP que no reciben peticiones directas de Internet, HTTP origin servers. Al escribir una implementación de un protocolo de pasarela, como CGI, FastCGI, SCGI, etcétera, que use una cabecera `Status:` para enviar un estado HTTP, probablemente sea adecuado heredar de esta clase, en lugar de `SimpleHandler`.

class `wsgiref.handlers.``SimpleHandler`(stdin, stdout, stderr, environ, multithread=True, multiprocess=False)

  Similar a `BaseCGIHandler` pero diseñada para usarse con servidores que reciban peticiones directamente de Internet, o HTTP origin servers. Al escribir una implementación de un servidor HTTP, probablemente prefiera heredar de esta clase en lugar de `BaseCGIHandler`.

  Esta clase es una subclase de `BaseHandler`. Sobreescribe los métodos `__init__()`, `get_stdin()`, `get_stderr()`, `add_cgi_vars()`, `_write()` y `_flush()` para soportar el uso explícito del entorno y los flujos a partir del constructor. El entorno y los flujos especificados se almacenan en los atributos `stdin`, `stdout`, `stderr` y `environ`.

  El método `write()` de stdout podría escribir cada fragmento de información completamente, como `io.BufferedIOBase`.

class `wsgiref.handlers.``BaseHandler`

  Esta es una clase base abstracta para ejecutar aplicaciones WSGI. Cada instancia gestionará una sola petición HTTP, aunque en principio se podría crear una subclase reutilizable para múltiples peticiones.

  Las instancias de `BaseHandler` tiene un sólo método para uso externo:

  `run`(app)

    Ejecuta la aplicación WSGI app indicada.

  Todos los otros métodos de `BaseHandler` se invocan por este método en el proceso de ejecutar la aplicación, es decir, existen principalmente para permitir personalizar el proceso.

  Los métodos siguientes DEBEN sobrescribirse en una subclase:

  `_write`(data)

    Enviar los bytes data para la transmisión al cliente. Es correcto que este método realmente transmita la información. La clase `BaseHandler` simplemente separa las operaciones de escritura y liberación para una mayor eficiencia cuando el sistema subyacente realmente hace esa distinción.

  `_flush`()

    Forzar la transmisión de los datos en el búfer al cliente. Es correcto si este método no es operativo, p.e., si `_write()` realmente envía los datos.

  `get_stdin`()

    Retorna un objeto de flujo de entrada disponible para usar como `wsgi.input` de la petición en proceso actualmente.

  `get_stderr`()

    Retorna un objeto de flujo de salida disponible para usar como `wsgi.errors` de la petición en proceso actualmente.

  `add_cgi_vars`()

    Inserta las variables CGI para la petición actual en el atributo `environ`.

  A continuación se describen algunos métodos y atributos más que podría ser interesante sobrescribir. Esta lista es sólo un sumario, sin embargo, y no incluye cada método que puede ser sobrescrito. Conviene consultar las docstrings y el código fuente para obtener información adicional antes de intentar crear una subclase de `BaseHandler` personalizada.

  Atributos y métodos para personalizar el entorno WSGI:

  `wsgi_multithread`

    El valor a usar en la variable de entorno `wsgi.multithread`. Por defecto es cierto en `BaseHandler`, pero puede tener un valor por defecto distinto (o establecerse en el constructor) en otras subclases.

  `wsgi_multiprocess`

    El valor a usar en la variable de entorno `wsgi.multiprocess`. Por defecto es cierto en `BaseHandler`, pero puede tener un valor por defecto distinto (o establecerse en el constructor) en otras subclases.

  `wsgi_run_once`

    El valor a usar en la variable de entorno `wsgi.run_once`. Por defecto es falso en `BaseHandler`, pero en `CGIHandler` es cierto por defecto.

  `os_environ`

    Las variables de entorno por defecto que se incluirán en el entorno WSGI de cada petición. Por defecto, es una copia de `os.environ` cuando se importa `wsgiref.handlers`, pero otras subclases pueden crear las suyas propias a nivel de clase o de instancia. Se debe tener en cuenta que el diccionario se debe considerar como de sólo lectura, ya que el valor por defecto se comparte entre múltiples clases e instancias.

  `server_software`

    Si el atributo `origin_server` tiene valor, éste se usa para establecer el valor por defecto de la variable de entorno WSGI `SERVER_SOFTWARE` y un cabecera `Server:` por defecto en las respuestas HTTP. Las clases gestoras que no son HTTP origin servers, como `BaseCGIHandler` y `CGIHandler`, ignoran este atributo.

    Distinto en la versión 3.3: El término «Python» se reemplaza con el término específico correspondiente a la implementación del intérprete, como «CPython», «Jython», etc.

  `get_scheme`()

    Retorna el esquema usado en la URL para la petición actual. La implementación por defecto utiliza la función `guess_scheme()` de `wsgiref.util` para adivinar si el esquema debería ser «http» o «https», basándose en las variables de `environ` de la petición actual.

  `setup_environ`()

    Establece el atributo `environ` a un entorno WSGI completo. La implementación por defecto utiliza todos los métodos y atributos anteriormente mencionados, más los métodos `get_stdin()`, `get_stderr()` y `add_cgi_vars()`, y el atributo `wsgi_file_wrapper`. También incluye una clave `SERVER_SOFTWARE` si no existe, siempre y cuando el atributo `origin_server` tiene un valor válido y el atributo `server_software` está establecido.

  Métodos y atributos para personalizar el manejo de excepciones:

  `log_exception`(exc_info)

    Envía la tupla exc_info al registro del servidor. exc_info es un tupla `(type, value, traceback)`. La implementación por defecto simplemente escribe el seguimiento de la pila en el flujo `wsgi.errors` de la petición y lo vacía. Las subclases pueden sobrescribir éste método para cambiar el formato o redirigir la salida, enviar mensajes de correo con el seguimiento de pila a un administrador o cualquier otra acción que se considere adecuada.

  `traceback_limit`

    El máximo número de marcos a incluir en la salida de seguimientos de pilas por el método por defecto `log_exception()`. Si vale `None`, se incluyen todos los marcos.

  `error_output`(environ, start_response)

    Este método es una aplicación WSGI para generar una página de error para el usuario. Sólo se invoca si un error ocurre antes de enviar las cabeceras al cliente.

    Este método puede acceder a la información de error actual usando `sys.exc_info()` y debería pasar esa información a start_response cuando es llamada, tal y como se describe en la sección «Error Handling» de PEP 3333.

    La implementación por defecto sólo utiliza los atributos `error_status`, `error_headers` y `error_body` para generar una página de salida. Las subclases pueden sobrescribir éste para producir una salida de error dinámica mejor.

    Hay que tener en cuenta, sin embargo, que no se recomienda, desde una perspectiva de seguridad, mostrar información de diagnóstico a cualquier usuario antiguo. Idealmente, se debería hacer algo especial para activar la salida de información de diagnóstico, motivo por el que la implementación por defecto no incluye ninguna.

  `error_status`

    El estado HTTP utilizado para las respuestas de error. Se debería utilizar una de las cadenas de estado definidas en PEP 3333. Por defecto es un código 500 y un mensaje.

  `error_headers`

    Las cabeceras HTTP utilizadas por las respuestas de error. Debería tratarse de una lista de cabeceras de respuesta WSGI (tuplas `(name, value)`), tal y como se describe en PEP 3333. La lista por defecto simplemente establece el tipo de contenido a `text/plain`.

  `error_body`

    El cuerpo de la respuesta de error. Debería ser una cadena de bytes con el cuerpo de la respuesta HTTP. Por defecto contiene el texto plano A server error occurred. Please contact the administrator.

  Métodos y atributos para la funcionalidad «Optional Platform-Specific File Handling» de PEP 3333:

  `wsgi_file_wrapper`

    Una factoría `wsgi.file_wrapper`, o `None`. El valor por defecto de este atributo es la clase `wsgiref.util.FileWrapper`.

  `sendfile`()

    Sobrescribir para implementar la transmisión de ficheros específica para la plataforma. Este método se llama sólo si el valor de retorno de la aplicación es una instancia de la clase especificada por el atributo `wsgi_file_wrapper`. Debería retornar un valor cierto si fue capaz de transmitir correctamente el fichero, de modo que el código por defecto de transmisión no será ejecutado. La implementación por defecto de este método simplemente retorna un valor falso.

  Métodos y atributos varios:

  `origin_server`

    Este atributo debería establecerse a cierto si los métodos `_write()` y `_flush()` están siendo usados para comunicar directamente al cliente, en lugar de usar un protocolo de pasarela CGI que requiere el estado HTTP en una cabecera `Status:` especial.

    El valor por defecto de este atributo es cierto en `BaseHandler`, pero en `BaseCGIHandler` y `CGIHandler` es falso.

  `http_version`

    Si `origin_server` es cierto, este atributo de tipo cadena se usa para establecer la versión HTTP de la respuesta enviada al cliente. Por defecto es `"1.0"`.

`wsgiref.handlers.``read_environ`()

  Transcodifica las variables CGI de `os.environ` a cadenas «bytes in unicode» definidas en PEP 3333, retornando un nuevo diccionario. Esta función se usa en `CGIHandler` y `IISCGIHandler` en lugar de usar directamente `os.environ`, lo que no es necesariamente compatible con EWGI en todas las plataformas y servidores web usando Python 3 – específicamente, aquellas en las que el entorno actual del sistema operativo es Unicode, p.e. Windows, o en las que el entorno está en bytes, pero la codificación del sistema usada por Python para descodificar lo es cualquier otro que ISO-8859-1, por ejemplo, sistemas UNIX que usen UTF-8.

  Cuando se está implementando un gestor basado en CGI propio, probablemente se requiera usar esta rutina en lugar de sólo copiar directamente los valores de `os.environ`.

  Nuevo en la versión 3.2.

## Ejemplos

Ésta es una aplicación WSGI «Hello World» que funciona:

    from wsgiref.simple_server import make_server

    # Every WSGI application must have an application object - a callable
    # object that accepts two arguments. For that purpose, we're going to
    # use a function (note that you're not limited to a function, you can
    # use a class for example). The first argument passed to the function
    # is a dictionary containing CGI-style environment variables and the
    # second variable is the callable object.
    def hello_world_app(environ, start_response):
        status = '200 OK'  # HTTP Status
        headers = [('Content-type', 'text/plain; charset=utf-8')]  # HTTP Headers
        start_response(status, headers)

        # The returned object is going to be printed
        return [b"Hello World"]

    with make_server('', 8000, hello_world_app) as httpd:
        print("Serving on port 8000...")

        # Serve until process is killed
        httpd.serve_forever()

Ejemplo de una aplicación WSGI que sirve el directorio actual, acepta un directorio opcional y un número de puerto (default: 8000) en la línea de comandos:

    #!/usr/bin/env python3
    '''
    Small wsgiref based web server. Takes a path to serve from and an
    optional port number (defaults to 8000), then tries to serve files.
    Mime types are guessed from the file names, 404 errors are raised
    if the file is not found. Used for the make serve target in Doc.
    '''
    import sys
    import os
    import mimetypes
    from wsgiref import simple_server, util

    def app(environ, respond):

        fn = os.path.join(path, environ['PATH_INFO'][1:])
        if '.' not in fn.split(os.path.sep)[-1]:
            fn = os.path.join(fn, 'index.html')
        type = mimetypes.guess_type(fn)[0]

        if os.path.exists(fn):
            respond('200 OK', [('Content-Type', type)])
            return util.FileWrapper(open(fn, "rb"))
        else:
            respond('404 Not Found', [('Content-Type', 'text/plain')])
            return [b'not found']

    if __name__ == '__main__':
        path = sys.argv[1] if len(sys.argv) > 1 else os.getcwd()
        port = int(sys.argv[2]) if len(sys.argv) > 2 else 8000
        httpd = simple_server.make_server('', port, app)
        print("Serving {} on port {}, control-C to stop".format(path, port))
        try:
            httpd.serve_forever()
        except KeyboardInterrupt:
            print("Shutting down.")
            httpd.server_close()