Encabezados de solicitud y respuestas

ID de región

REGION_ID es un código abreviado que Google asigna en función de la región que seleccionas cuando creas la app. El código no corresponde a un país ni a una provincia, aunque algunos ID de región puedan parecer similares a los códigos de país y provincia que se suelen usar. En el caso de las apps creadas después de febrero de 2020, REGION_ID.r se incluye en las URL de App Engine. En el caso de las apps existentes creadas antes de esta fecha, el ID de región es opcional en la URL.

Obtén más información acerca de los ID de región.

Aceptar

Usa esta página de referencia para obtener detalles sobre los encabezados HTTP compatibles, y los límites de solicitudes y respuestas de App Engine. Para comprender cómo App Engine recibe solicitudes y envía respuestas, consulta Cómo se manejan las solicitudes.

Encabezados de la solicitud

Una solicitud HTTP entrante incluye los encabezados HTTP que envía el cliente. Por razones de seguridad, los proxies intermedios limpian, modifican o quitan algunos encabezados antes de que lleguen a la aplicación.

Encabezados que se quitan de las solicitudes entrantes

Los siguientes encabezados se quitan de las solicitudes entrantes si un cliente los envía:

• Encabezados con nombres que coinciden con el patrón X-Google-*. Este patrón de nombre está reservado para Google

• Encabezados con nombres que coinciden con encabezados específicos de App Engine. Solo se quitan las coincidencias exactas, que no distinguen entre mayúsculas y minúsculas. Por ejemplo, se quitarán los encabezados llamados X-Appengine-Country o X-AppEngine-Country, pero no X-Appengine-Cntry

Además, se quitan los siguientes encabezados de las solicitudes entrantes porque se relacionan con la transferencia de los datos HTTP entre el cliente y el servidor:

• Accept-Encoding
• Connection
• Keep-Alive
• Proxy-Authorization
• TE
• Trailer
• Transfer-Encoding

Por ejemplo, el servidor puede enviar de forma automáticamente una respuesta en formato gzip, según el valor del encabezado de solicitud Accept-Encoding. La aplicación no necesita saber qué codificaciones de contenido puede aceptar el cliente.

Nota: Los encabezados de las entidades (encabezados relacionados con el cuerpo de la solicitud) no se limpian ni se verifican, por lo que las aplicaciones no deben depender de ellos. En particular, el encabezado de la solicitud Content- MD5 se envía sin modificar a la aplicación, por lo que es posible que no coincida con el hash MD5 del contenido. Además, el servidor no verifica el encabezado de solicitud Content-Encoding, por lo que si el cliente envía un cuerpo de solicitud en formato gzip, se enviará en formato comprimido a la aplicación.

Solicitudes y WSGI

El servidor determina a qué objeto de aplicación de Python llamar mediante la comparación de la URL de la solicitud con los patrones de la URL en el archivo de configuración de la aplicación. A continuación, llama al objeto de la aplicación a través de los argumentos definidos en el estándar WSGI. El objeto de la aplicación realiza acciones adecuadas para la solicitud, luego prepara una respuesta y la muestra como una lista de strings.

La mayoría de las aplicaciones usan un framework, como webapp2, para manejar las solicitudes WSGI. webapp2 se incluye como parte del entorno de ejecución de Python 2.7.

Solicitudes y CGI

Advertencia: CGI se incluye para la retrocompatibilidad, y no se recomienda su uso. Si es posible, usa WSGI.

El servidor determina qué secuencia de comandos del controlador de PHP se debe ejecutar. Para hacerlo, compara la URL de la solicitud y los patrones de URL del archivo de configuración de la app. Luego, ejecuta la secuencia de comandos en un entorno propagado con los datos de la solicitud. Como se describe en el estándar de CGI, el servidor coloca los datos de la solicitud en las variables de entorno y en el flujo de entrada estándar. La secuencia de comandos realiza las acciones adecuadas para la solicitud y, luego, prepara una respuesta y la coloca en el flujo de salida estándar.

La mayoría de las aplicaciones usan una biblioteca para analizar solicitudes CGI y mostrar respuestas CGI, como el módulo cgi de la biblioteca estándar de Python o un framework web que conozca el protocolo CGI (como webapp). Puedes consultar la documentación de CGI para obtener detalles sobre las variables de entorno y el formato de los datos de flujo de entrada.

Encabezados específicos de App Engine

Como un servicio para la app, App Engine agrega los siguientes encabezados a todas las solicitudes:

X-Appengine-Country

País donde se originó la solicitud, como un código de país ISO 3166-1 Alfa-2. App Engine define este código a partir de la dirección IP del cliente. Ten en cuenta que la información del país no proviene de la base de datos de WHOIS. Es posible que una dirección IP con información del país en la base de datos de WHOIS no tenga la información del país en el encabezado X-Appengine-Country. La aplicación debe controlar el código especial de país ZZ (país desconocido).

X-Appengine-Region

Nombre de la región donde se originó la solicitud. Este valor solo tiene sentido en el contexto del país en X -Appengine-Country. Por ejemplo, si el país es “EE.UU.” y la región es “ca”, significa “California”, no Canadá. La lista completa de valores de región válidos se encuentra en el estándar ISO-3166-2.

X-Appengine-City

Nombre de la ciudad donde se originó la solicitud. Por ejemplo, una solicitud de la ciudad de Mountain View puede tener el valor de encabezado mountain view. No existe una lista canónica de valores válidos para este encabezado.

X-Appengine-CityLatLong

La latitud y longitud de la ciudad donde se originó la solicitud. Esta string podría ser “37.386051,-122.083851” para una solicitud de Mountain View.

X-Cloud-Trace-Context

Un identificador único para la solicitud que se usa en Cloud Trace y Cloud Logging. No hay una opción para inhabilitar este encabezado o elegir la tasa de muestreo de seguimiento, ya que todas las apps del entorno estándar de App Engine se rastrean automáticamente.

X-Forwarded-For: [CLIENT_IP(s)], [global forwarding rule IP]

Una lista delimitada por comas de direcciones IP a través de la que se enruta la solicitud del cliente. La primera IP de esta lista suele ser la IP del cliente que creó la solicitud. Las IP subsiguientes proporcionan información sobre los servidores proxy que también controlaron la solicitud antes de que se alcanzara el servidor de aplicaciones. Por ejemplo:

X-Forwarded-For: clientIp, proxy1Ip, proxy2Ip

X-Forwarded-Proto [http | https]

Muestra http o https según el protocolo que el cliente usó para conectarse a tu aplicación.

El balanceador de cargas de Google Cloud finaliza todas las conexiones https y reenvía el tráfico a instancias de App Engine a través de http. Por ejemplo, si un usuario solicita acceso a tu sitio a través de https://PROJECT_ID.REGION_ID.r.appspot.com, el valor del encabezado X-Forwarded-Proto es https.

Además, App Engine puede establecer los siguientes encabezados que son para su uso interno:

• X-Appengine-Https
• X-Appengine-User-IP
• X-Appengine-Api-Ticket
• X-Appengine-Request-Log-Id
• X-Appengine-Default-Version-Hostname
• X-Appengine-Timeout-Ms

Los servicios de App Engine pueden agregar encabezados de solicitud adicionales:

• Para los controladores login:admin o login:required especificados en app.yaml, App Engine agrega el siguiente conjunto de encabezados:

  • X-Appengine-User-Email, con el encabezado de ejemplo: “[e-mail]”
  • X-Appengine-Auth-Domain,con el encabezado de ejemplo: “example.com”
  • X-Appengine-User-ID, con el encabezado de ejemplo: “100979712376541954724”
  • X-Appengine-User-Nickname, con el encabezado de ejemplo: “ange”
  • X-Appengine-User-Organization, con el encabezado de ejemplo: “example.com”
  • X-Appengine-User-Is-Admin, con el encabezado de ejemplo: “1”

• El servicio de lista de tareas en cola agrega encabezados adicionales a las solicitudes de esa tarea que proporcionan detalles sobre la tarea en la solicitud y la cola con la que está asociado.

• Las solicitudes del servicio cron agregan el siguiente encabezado:

  X-Appengine-Cron: true

  Consulta la sección sobre cómo proteger las URL para cron a fin de obtener más información.

• Las solicitudes que provienen de otras aplicaciones de App Engine incluirán un encabezado que identifique la app que realiza la solicitud, si la app solicitante usa el servicio de recuperación de URL:

  X-Appengine-Inbound-Appid

  Consulta la documentación de App Identity para obtener más detalles.

Respuestas a solicitudes

Esta documentación del encabezado HTTP solo se aplica a las respuestas a las solicitudes HTTP entrantes. La respuesta se puede modificar antes de que se muestre al cliente. Para los encabezados HTTP relacionados con las solicitudes salientes que origina el código de App Engine, consulta la documentación del encabezado de URLFetch.

Encabezados que se quitan

Los siguientes encabezados se ignoran y se quitan de la respuesta:

• Connection
• Content-Encoding*
• Content-Length
• Date
• Keep-Alive
• Proxy-Authenticate
• Server
• Trailer
• Transfer-Encoding
• Upgrade

* Se puede volver a agregar si App Engine comprime la respuesta.

También se quitan los encabezados que poseen caracteres que no son ASCII en el nombre o el valor.

Encabezados que se agregan o reemplazan

Los siguientes encabezados se agregan o reemplazan en la respuesta:

Cache-Control, Expires y Vary

Estos encabezados especifican la política de almacenamiento en caché para proxies web intermedios (como el frontend de Google y los proveedores de servicios de Internet) y navegadores. Si se establecen estos encabezados de respuesta en la app, por lo general, no se modificarán a menos que la app también establezca un encabezado Set-Cookie, o la respuesta se genere para un usuario que haya accedido mediante una cuenta de administrador.

Si tu app establece un encabezado de respuesta Set-Cookie, el encabezado Cache-Control se establecerá en private (si no es más restrictivo) y el encabezado Expires se establecerá en la fecha actual (si no está en una fecha pasada). Por lo general, esto permitirá que los navegadores almacenen en caché la respuesta, pero no permitirá que lo hagan los servidores proxy intermedios. Esto es por motivos de seguridad, ya que, si la respuesta se almacena en caché de forma pública, otro usuario podría solicitar más tarde el mismo recurso y recuperar la cookie del primer usuario.

Nota: El servidor de desarrollo inhabilita el almacenamiento en caché de forma predeterminada (para las secuencias de comandos y el contenido estático). Si no especificas encabezados de almacenamiento en caché, no tendrás contenido almacenado en caché mientras desarrolles tu app.

Si usas un marco de trabajo basado en webob (como webapp o webapp2), el marco de trabajo establece el encabezado Cache-Control en no-cache de forma predeterminada, por lo que debes anularlo si deseas almacenar en caché en tu controladores de secuencia de comandos.

Si la app no establece el encabezado de respuesta Cache-Control, el servidor puede establecerlo en private y agregar un encabezado Vary: Accept-Encoding.

Para obtener más información sobre el almacenamiento en caché, incluida la lista de valores Vary compatibles con el frontend de Google, consulta Almacenamiento en caché de respuesta.

Content-Encoding

Según el Content-Type de los encabezados de solicitud y respuestas, el servidor puede comprimir de forma automática el cuerpo de la respuesta, como se describió antes. En este caso, se agrega un encabezado Content-Encoding: gzip para indicar que el cuerpo está comprimido. Consulta la sección sobre compresión de la respuesta para obtener más detalles.

Content-Length o Transfer-Encoding

El servidor siempre ignora el encabezado Content-Length que muestra la aplicación. Establecerá Content-Length en la longitud del cuerpo (después de la compresión, si se aplica) o borrará Content-Length y usará la codificación de transferencia fragmentada (si se agrega un encabezado Transfer-Encoding: chunked).

Content-Type

Si la aplicación no lo especifica, el servidor establecerá un encabezado Content-Type: text/html predeterminado.

Nota: Si usas un framework basado en webob (como webapp o webapp2), el encabezado Content-Type se establece en text/html; charset=utf-8 de forma predeterminada. por lo que no se aplica este valor predeterminado (sin una propiedad charset).

Date

Configura la fecha y hora actuales.

Server

Se define en Google Frontend. El servidor de desarrollo establece esto como Development/x, en el que x es el número de la versión.

Si accedes a páginas dinámicas en tu sitio cuando accedes con una cuenta de administrador, App Engine incluye estadísticas por solicitud en los encabezados de respuesta:

X-Appengine-Resource-Usage

Los recursos que usa la solicitud, incluido el tiempo del servidor, como una cantidad de milisegundos.

Las respuestas con estadísticas de uso de recursos quedarán como no almacenables en caché.

Si el encabezado X-Appengine-BlobKey está en la respuesta de la aplicación, este y el encabezado X-Appengine-BlobRange opcional se usarán para reemplazar el cuerpo de todo el contenido del BLOB de blobstore o de una parte de él. Si la aplicación no especifica Content-Type, se establecerá en el tipo de MIME del BLOB. Si se solicita un rango, el estado de la respuesta se cambiará a 206 Partial Content y se agregará un encabezado Content-Range. Se quitarán los encabezados X-Appengine-BlobKey y X-Appengine-BlobRange de la respuesta. Por lo general, no es necesario que configures estos encabezados, ya que la clase blobstore_handlers.BlobstoreDownloadHandler los configura. Consulta Entrega un BLOB para obtener más detalles.

Encabezados de respuesta establecidos en la configuración de la aplicación

Los encabezados de respuesta HTTP personalizados se pueden configurar por URL para las rutas de acceso dinámicas y estáticas en el archivo de configuración de tu aplicación. Consulta las secciones sobre http_headers en la documentación de la configuración para obtener más detalles.