Python 38.8 ahora está disponible a nivel general.

Cómo se manejan las solicitudes

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 tu 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. Incluir REGION_ID.r en las URL de App Engine es opcional para las apps existentes, y pronto será obligatorio para todas las apps nuevas.

A fin de garantizar una transición sin problemas, estamos actualizando App Engine de forma paulatina para usar los ID de región. Si aún no actualizamos tu proyecto de Google Cloud, no verás un ID de región para la app. Dado que el ID es opcional en las apps existentes, no es necesario que actualices las URL ni realices otros cambios una vez que el ID de región esté disponible en las apps existentes.

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

En este documento, se describe cómo tu aplicación de App Engine recibe solicitudes y envía respuestas. Para obtener más detalles, consulta la referencia de encabezados de solicitud y respuestas.

Si tu aplicación usa servicios, puedes dirigir solicitudes a un servicio específico o a una versión específica de ese servicio. Para obtener más información sobre cómo direccionar el servicio, consulta Cómo enrutar solicitudes.

Cómo controlar las solicitudes

La aplicación se encarga de iniciar un servidor web y controlar las solicitudes. Puedes usar cualquier framework web que esté disponible para tu lenguaje de desarrollo.

App Engine ejecuta varias instancias de tu aplicación, y cada una tiene su propio servidor web para manejar solicitudes. Estas pueden enrutarse a cualquier instancia, por lo que las solicitudes consecutivas del mismo usuario no necesariamente se envían a la misma instancia. Una instancia puede manejar varias solicitudes al mismo tiempo. La cantidad de instancias se puede ajustar de forma automática a medida que cambia el tráfico. También puedes cambiar la cantidad de solicitudes simultáneas que puede controlar una instancia si configuras el elemento max_concurrent_requests en el archivo app.yaml.

Cuotas y límites

App Engine asigna recursos a tu aplicación de manera automática a medida que el tráfico aumenta. Sin embargo, esto se limita con las siguientes restricciones:

  • App Engine reserva la capacidad de ajuste de escala automático para aplicaciones con latencia baja a fin de que la aplicación responda a las solicitudes en menos de un segundo. Las aplicaciones con latencia muy alta, como las de más de un segundo por solicitud para varias solicitudes, y con capacidad de procesamiento alta requieren asistencia nivel Plata, Oro o Platino. Los clientes con este nivel de asistencia pueden comunicarse con su representante de asistencia para solicitar el aumento de sus límites de capacidad de procesamiento.

  • Las aplicaciones estrechamente vinculadas a la CPU también pueden incurrir en alguna latencia adicional para compartir recursos de manera eficaz con otras aplicaciones en el mismo servidor. Las solicitudes para archivos estáticos están exentas de estos límites de capacidad de latencia.

Cada solicitud que entra a la aplicación se tiene en cuenta para los límites de Solicitudes. Los datos enviados en respuesta a una solicitud se tienen en cuenta para el límite de Ancho de banda de salida (facturable).

Las solicitudes HTTP y las HTTPS (seguras) se tienen en cuenta para los límites de Solicitudes, Ancho de banda entrante (facturable) y Ancho de banda saliente (facturable). En la página Detalles de cuota de Cloud Console, también se informan las Solicitudes seguras, el Ancho de banda entrante seguro y el Ancho de banda saliente seguro como valores separados. Solo se tienen en cuenta las solicitudes HTTPS para estos valores. Para obtener más información, consulta la página de Cuotas.

Los siguientes límites se aplican específicamente al uso de los controladores de solicitudes:

Límite Importe
tamaño de la solicitud 32 megabytes
tamaño de la respuesta 32 megabytes
tiempo de espera de la solicitud depende del tipo de escalamiento que use la app
cantidad total máxima de archivos (archivos estáticos y de la app) 10,000 en total
1,000 por directorio
tamaño máximo de un archivo de la aplicación 32 megabytes
tamaño máximo de un archivo estático 32 megabytes
tamaño total máximo de todos los archivos estáticos y de la aplicación el primer gigabyte es gratis
$0.026 por gigabyte por mes después del primer gigabyte

Límites de las respuestas

Las respuestas dinámicas tienen un límite de 32 MB. Si un controlador de secuencia de comandos genera una respuesta superior a este límite, el servidor envía una respuesta vacía con un código de estado 500 “Error interno del servidor”. Esta limitación no se aplica a las respuestas que entregan datos desde Blobstore o Cloud Storage.

Encabezados de solicitud

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

Para obtener más información, consulta la referencia de encabezados de solicitud.

Especifica un plazo para la solicitud

App Engine está optimizado para aplicaciones con solicitudes de corta duración, que son, por lo general, las que llevan unos cientos de milisegundos. Una app eficiente responde con rapidez a la mayoría de las solicitudes. Si la app no puede hacerlo, no escalará bien con la infraestructura de App Engine.

Todas las solicitudes a la app deben mostrar una respuesta dentro del tiempo de espera máximo de la solicitud. Si la app no responde dentro del tiempo de espera, App Engine interrumpe el controlador de solicitudes.

Respuestas

Se aplican límites de tamaño a la respuesta que generas, y la respuesta se puede modificar antes de que se muestre al cliente.

Para obtener más información, consulta la referencia de respuestas a solicitudes.

Respuestas a transmisión

App Engine no admite la transmisión de respuestas, donde los datos se envían en fragmentos graduales al cliente mientras se procesa una solicitud. Todos los datos de tu código se recopilan como se describió anteriormente y se envían como una respuesta HTTP simple.

Compresión de las respuestas

Para las respuestas que muestra el código, App Engine comprime los datos en la respuesta si se cumplen las siguientes dos condiciones:

  • La solicitud contiene el encabezado Accept-Encoding que incluye gzip como un valor.
  • La respuesta contiene datos basados en texto, como HTML, CSS o JavaScript.

Para las respuestas que muestra un archivo estático o controlador de directorio de App Engine, los datos de respuesta se comprimen si se cumplen las siguientes condiciones:

  • La solicitud incluye Accept-Encoding con gzip como uno de sus valores.
  • El cliente puede recibir los datos de respuesta en un formato comprimido. El frontend de Google mantiene una lista de clientes que se sabe que tienen problemas con respuestas comprimidas. Estos clientes no recibirán datos comprimidos de controladores estáticos en la app, incluso si los encabezados de la solicitud contienen Accept-Encoding: gzip.
  • La respuesta contiene datos basados en texto, como HTML, CSS o JavaScript.

Ten en cuenta lo siguiente:

  • Un cliente puede forzar la compresión de los tipos de contenido basado en texto mediante la configuración de los encabezados de solicitud Accept-Encoding y User-Agent en gzip.

  • Si una solicitud no especifica gzip en el encabezado Accept-Encoding, App Engine no comprimirá los datos de respuesta.

  • El frontend de Google almacena en caché las respuestas de los controladores de directorios y archivos estáticos de App Engine. Según diferentes factores, como qué tipo de datos de respuesta se almacenan primero en caché, qué encabezados Vary especificaste en la respuesta y qué encabezados se incluyen en la solicitud, un cliente podría solicitar datos comprimidos, pero recibir datos sin comprimir, y viceversa. Para obtener más información, consulta Almacena respuestas en caché.

Almacena respuestas en caché

El frontend de Google y, tal vez, el navegador del usuario y otros servidores proxy de almacenamiento en caché intermedia, almacenarán en caché las respuestas de la app según lo indican los encabezados de almacenamiento en caché estándar que especifiques en la respuesta. Puedes especificar estos encabezados de respuesta a través del framework, directamente en el código o a través de los controladores de directorios y archivos estáticos de App Engine.

En el frontend de Google, la clave de caché es la URL completa de la solicitud.

Almacena el contenido estático en caché

Para garantizar que los clientes siempre reciban contenido estático actualizado en cuanto se publique, te recomendamos que entregues contenido estático de directorios con versión, como css/v1/styles.css. El frontend de Google no validará la caché (verifica si hay contenido actualizado) hasta que venza. Incluso después de que se venza la caché, no se actualizará hasta que cambie el contenido en la URL de la solicitud.

Los siguientes encabezados de respuesta que puedes establecer en app.yaml influyen en cómo y cuándo el frontend de Google almacena contenido en caché:

  • Cache-Control: Se debe configurar como public para que el frontend de Google almacene el contenido en la caché. Si no configuras este encabezado en app.yaml, App Engine lo agrega de forma automática para todas las respuestas que administra un controlador de directorios o archivos estáticos. Para obtener más información, consulta Encabezados agregados o reemplazados.

  • Vary: Si quieres habilitar la caché a fin de que muestre respuestas diferentes para una URL según los encabezados que se envían en la solicitud, configura uno o más de los siguientes valores en el encabezado de respuesta Vary: Accept, Accept-Encoding, Origin o X-Origin.

    Debido a la posibilidad de cardinalidad alta, los datos no se almacenarán en caché para otros valores Vary.

    Por ejemplo:

    1. Especifica el siguiente encabezado de respuesta:

      Vary: Accept-Encoding

    2. La app recibe una solicitud que contiene el encabezado Accept-Encoding: gzip. App Engine muestra una respuesta comprimida, y el frontend de Google almacena en caché la versión comprimida de los datos de la respuesta. Todas las solicitudes posteriores para esta URL que contengan el encabezado Accept-Encoding: gzip recibirán los datos comprimidos de la caché hasta que se invalide la caché (debido a que el contenido cambia después de que se vence la caché).

    3. La app recibe una solicitud que no contiene el encabezado Accept-Encoding. App Engine muestra una respuesta sin comprimir, y el frontend de Google almacena en caché la versión sin comprimir de los datos de la respuesta. Todas las solicitudes posteriores para esta URL que no contengan el encabezado Accept-Encoding recibirán los datos comprimidos de la caché hasta que se invalide la caché.

    Si no especificas un encabezado de respuesta Vary, el frontend de Google crea una sola entrada de caché para la URL y la usará en todas las solicitudes, sin importar los encabezados de la solicitud. Por ejemplo:

    1. No debes especificar el encabezado de respuesta Vary: Accept-Encoding.
    2. Una solicitud contiene el encabezado Accept-Encoding: gzip y la versión comprimida de los datos de respuesta se almacenará en caché.
    3. Una segunda solicitud no contiene el encabezado Accept-Encoding: gzip. Sin embargo, debido a que la caché contiene una versión comprimida de los datos de la respuesta, la respuesta se comprimirá, a pesar de que el cliente solicitó datos sin comprimir.

Los encabezados de la solicitud también influyen en el almacenamiento en caché:

  • Si la solicitud contiene un encabezado Authorization, el frontend de Google no almacenará el contenido en caché.

Vencimiento de la caché

De forma predeterminada, los encabezados de almacenamiento en caché que los controladores de directorios y archivos estáticos de App Engine agregan a las respuestas indican a los clientes y a los proxies web, como el frontend de Google, que establezcan el vencimiento del almacenamiento en caché después de 10 minutos.

Después de que un archivo se transmite con un tiempo de vencimiento determinado, por lo general, no hay forma de borrarlo de las memorias caché del proxy web, incluso si el usuario borra su propia caché del navegador. Volver a implementar una versión nueva de la app no restablecerá ninguna caché. Por lo tanto, si alguna vez planeas modificar un archivo estático, este debe tener un tiempo de vencimiento corto (menos de una hora). En la mayoría de los casos, el tiempo de vencimiento predeterminado de 10 minutos es adecuado.

Puedes cambiar el vencimiento predeterminado de todos los controladores de directorios y archivos estáticos si especificas el elemento default_expiration en el archivo app.yaml. Si quieres configurar horas de vencimiento específicas para los controladores individuales, especifica el elemento expiration dentro del elemento controlador en el archivo app.yaml.

El valor que especifiques en la hora de vencimiento de los elementos se usará para establecer los encabezados de respuesta HTTP Cache-Control y Expires.

Fuerza conexiones HTTPS

Por motivos de seguridad, todas las aplicaciones deben incentivar al cliente a conectarse mediante https. A fin de indicarle al navegador que elija https en lugar de http para una página determinada o un dominio completo, configura el encabezado Strict-Transport-Security en tus respuestas. Por ejemplo:

Strict-Transport-Security: max-age=31536000; includeSubDomains
Si quieres configurar este encabezado para cualquier contenido estático que entregue tu app, agrega el encabezado al controlador de directorios y archivos estáticos.

Si quieres configurar este encabezado para las respuestas que se generan a partir de tu código, usa la biblioteca flask-talisman.