Recuperación de URL para servicios agrupados en paquetes heredados

Go Java PHP Python

En esta página, se describe cómo emitir solicitudes HTTP y HTTPS y recibir respuestas mediante el servicio de recuperación de URLs.

A diferencia del entorno de ejecución de Python 2 en el que App Engine usa la recuperación de URL para todas las solicitudes salientes de forma predeterminada, a fin de usar la recuperación de URL en Python 3, debes llamar de forma explícita a biblioteca urlfetch.

Esta API es compatible con entornos de ejecución de primera generación y se puede usar en actualizaciones a los entornos de ejecución de segunda generación correspondientes. Si actualizas al entorno de ejecución de Python de App Engine, consulta la página Actualiza a entornos de ejecución de segunda generación para obtener más información sobre las opciones de migración para servicios empaquetados heredados.

Solicitudes

Puedes usar el servicio de recuperación de URLs, o las bibliotecas idiomáticas de lenguaje para emitir solicitudes salientes. En Python, puedes usar la biblioteca urlfetch directamente, o las bibliotecas urllib.request o requests para hacer solicitudes HTTP.

Protocolos de solicitud

Una aplicación puede recuperar una URL mediante HTTP o HTTPS. El protocolo que se debe usar se infiere del protocolo que se indica en la URL de destino.

La URL que se debe recuperar puede usar cualquier número de puerto en los siguientes rangos:

• 80 - 90
• 440 - 450
• 1024 - 65535

Si el puerto no se menciona en la URL, el protocolo lo determina. Las solicitudes HTTP usan el puerto 80 y las solicitudes HTTPS usan el puerto 443.

Métodos de la solicitud

Si emites solicitudes a través del servicio de recuperación de URLs, puedes usar cualquiera de los siguientes métodos HTTP:

• GET
• POST
• PUT
• HEAD
• DELETE
• PATCH

Una solicitud puede incluir encabezados HTTP y, en el caso de POST, PUT y PATCH, una carga útil.

Proxies de la solicitud

Ten en cuenta que el servicio de recuperación de URL usa un proxy compatible con HTTP/1.1 para obtener el resultado.

A fin de evitar que una aplicación pueda provocar una recursión de solicitudes sin fin, no se permite que un controlador de solicitudes obtenga su propia URL. Sin embargo, es posible provocar una recursión sin fin de otras maneras, por lo que debes tener cuidado si permites que los usuarios suministren URL que generen solicitudes de recuperación en tu aplicación.

Encabezados de la solicitud

Tu aplicación puede configurar encabezados HTTP para la solicitud saliente.

Por ejemplo, cuando se envía una solicitud HTTP POST, si no se configura de forma explícita un encabezado Content-Type, el encabezado se establece en x-www-form-urlencoded. Este es el tipo de contenido que se usa en los formularios web.

Por motivos de seguridad, la aplicación no puede modificar los siguientes encabezados:

• Content-Length
• Host
• Vary
• Via
• X-Appengine-Inbound-Appid
• X-Forwarded-For
• X-ProxyUser-IP

App Engine configura estos encabezados con valores precisos según corresponda. Por ejemplo, App Engine calcula el encabezado Content-Length a partir de los datos de la solicitud y lo agrega a la solicitud antes del envío.

Los siguientes encabezados indican el ID de la app que realiza la solicitud:

• User-Agent. Este encabezado se puede modificar, pero App Engine agregará una string de identificación para permitir que los servidores identifiquen las solicitudes de App Engine. La string agregada tiene el formato "AppEngine-Google; (+http://code.google.com/appengine; appid: APPID)", en el que APPID es el identificador de tu app.
• X-Appengine-Inbound-Appid. Este encabezado no se puede modificar y se agrega de forma automática si la solicitud se envía mediante el servicio de recuperación de URLscuando el parámetro para seguir redireccionamientos está establecido en False.

Tiempos de espera de la solicitud

Puedes establecer una fecha límite o un tiempo de espera para la solicitud. De forma predeterminada, el tiempo de espera de una solicitud es de 10 segundos.

Puedes enviar solicitudes síncronas y asíncronas. El siguiente comportamiento se aplica a la API de recuperación de URL:

• Solicitudes síncronas: la llamada de recuperación espera hasta que el host remoto muestre un resultado y luego le devuelve el control a la aplicación. Si se excede el tiempo de espera máximo para la llamada de recuperación, esta genera una excepción.
• Solicitudes asíncronas: el servicio de recuperación de URL comienza la solicitud y luego muestra un objeto de manera inmediata. La aplicación puede realizar otras tareas mientras se recupera la URL. Cuando la aplicación necesita los resultados, llama un método en el objeto, el cual espera a que termine la solicitud si es necesario, y luego muestra el resultado. Si hay alguna solicitud de recuperación de URL pendiente cuando se cierra el controlador de solicitudes, el servidor de la aplicación espera a que todas las solicitudes restantes regresen o alcancen su plazo antes de mostrarle una respuesta al usuario.

Conexiones seguras y HTTPS

Tu aplicación puede recuperar una URL de forma segura con HTTPS para conectarse a servidores seguros. Los datos de solicitud y respuesta se transmiten a través de la red en forma encriptada.

En la API de Python, el proxy de recuperación de URL no valida el host con el que se está contactando de forma predeterminada. Puedes agregar un argumento validate_certificate opcional al método fetch() para habilitar la validación del host.

Nota: El módulo urllib.request no proporciona métodos para validar hosts.

Respuestas

Si usas la API de recuperación de URL, ten en cuenta que el servicio de recuperación de URL muestra todos los datos de respuesta, lo que incluye la respuesta, el código, los encabezados y el cuerpo.

De manera predeterminada, si el servicio de recuperación de URL recibe una respuesta con un código de redireccionamiento, el servicio lo seguirá. El servicio seguirá hasta cinco respuestas de redireccionamiento y luego mostrará el recurso final. Puedesindicarle al servicio de recuperación de URLs que no siga redireccionamientos y que en su lugar muestre una respuesta de redireccionamiento a la aplicación.

Nota: La API de recuperación de URL impone límites en cuanto al tamaño de respuesta. Si la respuesta entrante excede el tamaño máximo, el servicio de recuperación de URL presenta una excepción. Consulta la sección de Cuotas y límites para obtener más detalles. Puedes indicarle a la API de recuperación de URL que trunque la respuesta en lugar de generar una excepción. Si usas las bibliotecas urlfetch, urllib.request o requests para recuperar las URLs, la respuesta siempre se trunca y no se genera ninguna excepción.

Usa la recuperación de URL en el servidor de desarrollo

Cuando tu aplicación se ejecuta en el servidor de desarrollo de App Engine en tu computadora, las llamadas al servicio de recuperación de URL se manejan de manera local. A fin de recuperar las URL, el servidor de desarrollo se comunica con los hosts remotos directamente desde tu computadora, y usa la configuración de red que emplea tu computadora para acceder a Internet.

Cuando pruebes las funciones de tu aplicación que recuperan URL, asegúrate de que tu computadora pueda acceder a los hosts remotos.

Cuotas y límites para la recuperación de URL

Para obtener más información acerca de las cuotas del servicio de recuperación de URLs, consulta Cuotas. Para ver el uso actual de la cuota de tu aplicación, ve a la página Detalles de la cuota en la consola de Google Cloud.

Ir a la página Detalles de la cuota

Además, se aplican los siguientes límites al uso del servicio de recuperación de URL:

Limit	Amount
Request size	10 megabytes
Request header size	16 KB (Note that this limits the maximum length of the URL that can be specified in the header)
Response size	32 megabytes
Maximum deadline (request handler)	60 seconds
Maximum deadline (Task Queue and cron job handler)	60 seconds