Nota: Java 8 llegó al fin de la asistencia el 31 de enero de 2024. Tus aplicaciones existentes de Java 8 continuarán ejecutándose y recibiendo tráfico. Sin embargo, App Engine podría bloquear la reimplementación de aplicaciones que usan entornos de ejecución después de la fecha de finalización de la asistencia. Te recomendamos que migres a la versión más reciente compatible de Java.

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 eliges 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.

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 la aplicación usa servicios, puedes direccionar 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.

Maneja 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.

Cuando App Engine recibe una solicitud web para tu aplicación, invoca el servlet que corresponde a la URL, como se describe en el archivo web.xml del directorio WEB-INF/ en la aplicación. Admite las especificaciones de la API del servlet de Java 2.5 o 3.1 para proporcionar los datos de solicitud al servlet y aceptar los datos de respuesta.

App Engine ejecuta varias instancias de la aplicación, y cada una tiene su propio servidor web para controlar las solicitudes. Las solicitudes se pueden enrutar a cualquier instancia, por lo que las solicitudes consecutivas del mismo usuario no necesariamente se envían a la misma instancia. La cantidad de instancias se puede ajustar de forma automática a medida que el tráfico cambia.

De forma predeterminada, cada servidor web procesa solo una solicitud a la vez. Para enviar varias solicitudes a cada servidor web en paralelo, agrega un elemento <threadsafe>true</threadsafe> al archivo appengine-web.xml.

La siguiente clase de servlet de ejemplo muestra un mensaje simple en el navegador del usuario.

// With @WebServlet annotation the webapp/WEB-INF/web.xml is no longer required.
@WebServlet(name = "requests", description = "Requests: Trivial request", urlPatterns = "/requests")
public class RequestsServlet extends HttpServlet {

  @Override
  public void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
    resp.setContentType("text/plain");
    resp.getWriter().println("Hello, world");
  }
}

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 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 saliente (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 la consola de Google Cloud 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
tiempo de espera de la solicitud pendiente	10 segundos
Tamaño máximo de un solo campo de encabezado de solicitud	8 kilobytes para los entornos de ejecución de segunda generación en el entorno estándar. Las solicitudes a estos entornos de ejecución con campos de encabezado que superen los 8 kilobytes mostrarán errores HTTP 400.

Límites de solicitudes

Todas las solicitudes HTTP/2 se convertirán en solicitudes HTTP/1.1 cuando se reenvíen al servidor de la aplicación.

Límites de la respuesta

Las respuestas dinámicas tienen un límite de 32 MB. Si un controlador de secuencia de comandos genera una respuesta que supera 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.
El límite del encabezado de respuesta es de 8 KB para los entornos de ejecución de segunda generación. Los encabezados de respuesta que excedan este límite mostrarán errores HTTP 502, con registros que muestran upstream sent too big header while reading response header from upstream.

Encabezados de la 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 Encabezados de solicitud.

Controla los tiempos de espera de las solicitudes

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. Para garantizar este nivel de rendimiento, hay un tiempo de espera de solicitud máximo impuesto por el sistema al que cada app debe responder.

Si tu app supera este plazo, App Engine interrumpe el controlador de solicitudes. Java Runtime Environment interrumpe el servlet con una excepción com.google.apphosting.api.DeadlineExceededException. Si el controlador de solicitudes no detecta esta excepción, el entorno de ejecución mostrará un error de servidor HTTP 500 al cliente.

Si el controlador de solicitudes detecta la excepción DeadlineExceededException, el entorno de ejecución le da tiempo al controlador de solicitudes (menos de un segundo) para preparar una respuesta personalizada. Si al controlador de solicitudes le toma más de un segundo preparar una respuesta personalizada después de que se genera la excepción, se generará un HardDeadlineExceededError.

DeadlineExceededExceptions y HardDeadlineExceededErrors forzarán la finalización de la solicitud y la instancia se detendrá.

Para averiguar cuánto tiempo resta antes de que se cumpla el plazo, la aplicación puede importar com.google.apphosting.api.ApiProxy y llamar a ApiProxy.getCurrentEnvironment().getRemainingMillis(). Esto resulta muy útil si la aplicación planifica iniciar algún trabajo que podría llevar demasiado tiempo. Si sabes que le lleva cinco segundos procesar una unidad de trabajo, pero getRemainingMillis() muestra menos tiempo, no tiene sentido iniciar esa unidad de trabajo.

Advertencia: La excepción DeadlineExceededException puede generarse desde cualquier parte del programa, incluidos los bloques finally, lo que podría dejar al programa en un estado no válido. Esto puede causar interbloqueos o errores inesperados en el código de subprocesamiento, ya que es posible que los bloqueos no se liberen. Una vez completada la solicitud, el entorno de ejecución detendrá el proceso del servidor, por lo que las solicitudes futuras no se verán afectadas. Sin embargo, se detendrá cualquier solicitud simultánea que se controle en el mismo proceso. Esto equivale a una llamada a Thread.stop en el subproceso principal. Para obtener más información, consulta Why is Thread.stop deprecated? (¿Por qué la función Thread.stop está obsoleta?). Por seguridad, no debes confiar en la DeadlineExceededException y, en su lugar, comprueba que tus solicitudes se completen mucho antes del límite de tiempo (mediante getRemainingMillis(), si es necesario).

Respuestas

App Engine llama al servlet con un objeto de solicitud y un objeto de respuesta y, luego, espera que el servlet propague el objeto de respuesta y lo muestre. Cuando el servlet lo muestra, se envían al usuario los datos en el objeto de respuesta.

Se aplican límites de tamaño a la respuesta que generas y la respuesta se puede modificar antes de que regrese 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

App Engine hace todo lo posible para entregar el contenido comprimido (en formato gzip) a los clientes que lo admiten. Para determinar si el contenido debe comprimirse, App Engine hace lo siguiente cuando recibe una solicitud:

Visualiza los encabezados Accept-Encoding y User-Agent en la solicitud para confirmar si el cliente puede recibir respuestas comprimidas de manera confiable. Con este enfoque, se evitan algunos errores conocidos con contenido en formato gzip en navegadores populares.
Visualiza el encabezado Content-Type que configuraste para el controlador de respuestas a fin de confirmar si la compresión del contenido es la opción correcta. Por lo general, la compresión es adecuada para los tipos de contenido basados en texto, no para los tipos de contenido binario.

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á 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 appengine-web.xml influyen en cómo y cuándo el frontend de Google almacena contenido en caché:

Cache-Control debe configurarse como public para que el frontend de Google almacene el contenido en caché. También puede almacenarse en caché mediante el frontend de Google, a menos que especifiques una directiva Cache-Control private o no-store. Si no configuras este encabezado en appengine-web.xml, 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 directorio y archivos estáticos si especificas el elemento static-files en el archivo appengine-web.xml.

Logging

La aplicación puede escribir información en los registros de aplicación mediante java.util.logging.Logger. Los datos de registro de la aplicación se pueden ver en la consola de Google Cloud mediante Cloud Logging. A cada solicitud registrada se le asigna un ID de solicitud, un identificador global único basado en la hora de inicio de la solicitud. La consola de Google Cloud puede reconocer los niveles de registro de la clase Logger y mostrar mensajes de forma interactiva en diferentes niveles.

App Engine captura todo lo que el servlet escribe en la transmisión de salida estándar (System.out) y la transmisión de errores estándar (System.err) y, además, esta información se registra en los registros de la aplicación. Las líneas escritas en la transmisión de salida estándar se registran en el nivel “INFO” y las líneas escritas en la transmisión de errores estándar se registran en el nivel “WARNING”. Cualquier framework de registro (como log4j) que registre en las transmisiones de salida o de errores funcionará. Sin embargo, para obtener un control más detallado de la visualización del nivel de registro en la consola de Google Cloud, el framework de registro debe usar un adaptador java.util.logging.

// With @WebServlet annotation the webapp/WEB-INF/web.xml is no longer required.
@WebServlet(
    name = "RequestLogging",
    description = "Requests: Logging example",
    urlPatterns = "/requests/log"
)
public class LoggingServlet extends HttpServlet {

  private static final Logger log = Logger.getLogger(LoggingServlet.class.getName());

  @Override
  public void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
    log.info("An informational message.");
    log.warning("A warning message.");
    log.severe("An error message.");
    // ...
  }
}

El SDK de Java de App Engine incluye un archivo logging.properties de plantilla en el directorio appengine-java-sdk/config/user/. Para usarlo, copia el archivo en tu directorio WEB-INF/classes (o en otra parte de WAR) y, luego, la propiedad del sistema java.util.logging.config.file en "WEB-INF/logging.properties" (o la ruta que elijas, en relación con la raíz de la aplicación). Puedes configurar las propiedades del sistema en el archivo appengine-web.xml de la siguiente manera:

<appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> ... <system-properties> <property name="java.util.logging.config.file" value="WEB-INF/logging.properties" /> </system-properties> </appengine-web-app>

El servlet registra los mensajes con el nivel de registro INFO (mediante log.info()). El nivel de registro predeterminado es WARNING, que quita los mensajes INFO del resultado. Para cambiar el nivel de registro, edita el archivo logging.properties.

Entorno

Todas las propiedades del sistema y las variables del entorno son privadas para tu aplicación. Configurar una propiedad del sistema solo afecta a la vista de la propiedad de la aplicación y no a la vista de JVM.

Puedes configurar las propiedades del sistema y las variables del entorno para la aplicación en el descriptor de implementación.

App Engine configura varias propiedades del sistema que identifican el entorno de ejecución:

com.google.appengine.runtime.environment es "Production" cuando se ejecuta en App Engine y "Development" cuando se ejecuta en el servidor de desarrollo.

Además de usar System.getProperty(), puedes acceder a las propiedades del sistema mediante nuestra API de tipo seguro. Por ejemplo:
```
if (SystemProperty.environment.value() ==
    SystemProperty.Environment.Value.Production) {
    // The app is running on App Engine...
}
```
com.google.appengine.runtime.version es el ID de la versión de entorno de ejecución, como "1.3.0". Puedes invocar lo siguiente para obtener la versión: String version = SystemProperty.version.get();.
com.google.appengine.application.id es el ID de la aplicación. Puedes invocar lo siguiente para obtener el ID: String ID = SystemProperty.applicationId.get();.
com.google.appengine.application.version es la versión principal y secundaria del servicio de la aplicación que se está ejecutando, como “X.Y”. El número de la versión principal (“X”) se especifica en el archivo appengine-web.xml del servicio. El número de la versión secundaria (“Y”) se configura de forma automática cuando cada versión de la app se sube a App Engine. Puedes invocar lo siguiente para obtener el ID: String ID = SystemProperty.applicationVersion.get();.

En el servidor web de desarrollador, la versión principal que se muestra siempre es la versión predeterminada del servicio y la versión secundaria siempre es “1”.

App Engine también configura las siguientes propiedades del sistema cuando inicializa JVM en un servidor de la aplicación:

file.separator
path.separator
line.separator
java.version
java.vendor
java.vendor.url
java.class.version
java.specification.version
java.specification.vendor
java.specification.name
java.vm.vendor
java.vm.name
java.vm.specification.version
java.vm.specification.vendor
java.vm.specification.name
user.dir

ID de instancia

Puedes administrar una solicitud con este código para recuperar el ID de la instancia:

com.google.apphosting.api.ApiProxy.getCurrentEnvironment().getAttributes().get("com.google.appengine.instance.id")

En el entorno de producción, un administrador que accede puede usar el ID en una URL: https://INSTANCE_ID-dot-VERSION_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com. La solicitud se enrutará a esa instancia específica. Si la instancia no puede controlar la solicitud, muestra un error 503 inmediato.

ID de solicitud

En el momento de la solicitud, puedes guardar el ID de solicitud, que es único para esa solicitud. El ID de solicitud se puede usar más adelante para relacionar una solicitud con los registros de esa solicitud.

En el siguiente código se muestra cómo obtener el ID de solicitud en el contexto de una solicitud:

com.google.apphosting.api.ApiProxy.getCurrentEnvironment().getAttributes().get("com.google.appengine.runtime.request_log_id")

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 la app, agrega el encabezado al controlador de directorios y archivos estáticos.

La mayoría de los frameworks y los servidores web de las apps proporcionan asistencia para configurar este encabezado en las respuestas que se generan a partir del código. Para obtener información sobre el encabezado Strict-Transport-Security en Spring Boot, consulta HTTP con Seguridad de Transporte Estricta (HSTS).

Administra el trabajo asíncrono en segundo plano

El trabajo en segundo plano es cualquier trabajo que tu app realice para una solicitud después de que entregaste la respuesta HTTP. Evita realizar tareas en segundo plano en la app y revisa el código para asegurarte de que todas las operaciones asíncronas finalicen antes de entregar la respuesta.

Para trabajos de larga duración, recomendamos usar Cloud Tasks. Con Cloud Tasks, las solicitudes HTTP son de larga duración y muestran una respuesta solo después de que finaliza cualquier trabajo asíncrono.