Descripción general de los mapas de URL

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Los balanceadores de cargas HTTP(S) de Google Cloud y Traffic Director usan un recurso de configuración de Google Cloud llamado mapa de URL para enrutar solicitudes HTTP(S) a servicios de backend o buckets de backend.

Por ejemplo, con un balanceador de cargas HTTP(S) externo, puedes usar un solo mapa de URL para enrutar solicitudes a diferentes destinos según las reglas configuradas en el mapa de URL:

  • Las solicitudes de https://example.com/video se envían a un servicio de backend.
  • Las solicitudes de https://example.com/audio se envían a un servicio de backend diferente.
  • Las solicitudes de https://example.com/images se envían a un depósito de backend de Cloud Storage.
  • Las solicitudes de cualquier otra combinación de host y ruta de acceso se envían a un servicio de backend predeterminado.

Los mapas de URL se usan con los siguientes productos de Google Cloud:

Existen dos tipos de recursos de mapas de URL disponibles: global y regional. El tipo de recurso que debes usar depende del esquema de balanceo de cargas del producto.

Producto Esquema de balanceo de cargas Tipo de recurso de mapa de URL Destinos admitidos
Balanceador de cargas de HTTP(S) externo global EXTERNAL_MANAGED Global, externo Servicios de backend, buckets de backend
Balanceador de cargas de HTTP(S) global externo (clásico) EXTERNAL Global, externo Servicios de backend, buckets de backend
Balanceador de cargas HTTP(S) regional externo EXTERNAL_MANAGED Regional y externo Servicios de backend
Balanceador de cargas HTTP(S) interno INTERNAL_MANAGED Regional, interno Servicios de backend
Traffic Director INTERNAL_SELF_MANAGED Global, interno Servicios de backend

No todas las funciones de mapas de URL están disponibles para todos los productos. Los mapas de URL que se usan con balanceadores de cargas de HTTP(S) externos globales, balanceadores de cargas de HTTP(S) externos regionales, balanceadores de cargas de HTTP(S) internos y Traffic Director también admiten varias funciones de administración avanzada del tráfico. Para obtener más información sobre estas diferencias, consulta Comparación de funciones del balanceador de cargas: enrutamiento y administración del tráfico.

Cómo funcionan los mapas de URL

Cuando una solicitud llega al balanceador de cargas, este la enruta a un servicio o buckets de backend en particular según las reglas definidas en el mapa de URL.

Un servicio de backend representa una colección de backends, que son instancias de una aplicación o un microservicio. Un bucket de backend es un bucket de Cloud Storage, que se usa en general para alojar contenido estático, como imágenes.

Para los balanceadores de cargas de HTTP(S) externos, HTTP(S) internos y Traffic Director, los destinos posibles son los siguientes:

Además, los balanceadores de cargas de HTTP(S) externos globales admiten lo siguiente:

Por ejemplo, supón que tienes la siguiente configuración:

  • Una dirección IP:
    • Todas las solicitudes a tu organización se envían a la misma dirección IP y al mismo balanceador de cargas.
    • El tráfico se dirige a diferentes servicios de backend según la URL de la solicitud.
  • Dos dominios:
    • example.net aloja videos de capacitación.
    • example.org aloja el sitio web de la organización.
  • Cuatro conjuntos de servidores:
    • Uno aloja el sitio web de la organización (servicio de backend: org-site).
    • Uno aloja el sitio web general del video de capacitación (servicio de backend: video-site).
    • Uno aloja videos de capacitación en alta definición (HD) (servicio de backend: video-hd).
    • Uno aloja videos de capacitación en definición estándar (SD) (servicio de backend: video-sd).

Lo que debe ocurrir es lo siguiente:

  • Las solicitudes a example.org (o cualquier dominio que no sea example.net) deben dirigirse al servicio de backend org-site.
  • Solicitudes a example.net que no coinciden con rutas de acceso más específicas deben dirigirse al servicio de backend video-site.
  • Solicitudes a example.net/video/hd/* deben dirigirse al servicio de backend video-hd.
  • Solicitudes a example.net/video/sd/* para ir al servicio de backend video-sd.

Un --path-rule para /video/* coincide con los URI como /video/test1, /video/test2, etcétera. Sin embargo, esta regla de ruta de acceso no coincide con la ruta /video.

Si el balanceador de cargas recibe una solicitud con /../ en la URL, el balanceador de cargas transforma la URL mediante la eliminación del segmento de ruta antes de .. y responde con la URL transformada. Por ejemplo, cuando se envía una solicitud para http://example.net/video/../abc, el balanceador de cargas responde con un redireccionamiento 302 a http://example.net/abc. Luego, la mayoría de los clientes reaccionan mediante una solicitud a la URL que muestra el balanceador de cargas (en este caso, http://example.net/abc). Este redireccionamiento 302 no se registra en Cloud Logging.

El mapa de URL te permite configurar este tipo de enrutamiento basado en host y ruta de acceso.

Ejemplo de configuración del servicio de backend (haz clic para ampliar)
Ejemplo de configuración del servicio de backend (haz clic para ampliar)

Nombre

Cada mapa de URL tiene un nombre. Cuando creas un balanceador de cargas basado en HTTP(S) mediante Google Cloud Console, se asigna un nombre al mapa de URL. Este nombre es el mismo que el nombre del balanceador de cargas en la consola de Google Cloud. Si usas Distribuye el tráfico a Cloud Storage o la API, puedes definir un nombre personalizado para el mapa de URL.

Componentes del mapa de URL

Un mapa de URL es un conjunto de recursos de configuración de Google Cloud que dirige las solicitudes de URL a servicios de backend o buckets de backend. Para hacerlo, el mapa de URL utiliza las partes nombre de host y ruta de acceso de cada URL que procesa:

  • Un nombre de host es la parte del nombre de dominio de una URL; por ejemplo, la parte del nombre del host de la URL http://example.net/video/hd es example.net.
  • Una ruta de acceso es la parte de una URL que sigue al nombre de host y el número de puerto opcional; por ejemplo, la parte de la ruta de acceso de la URL http://example.net/video/hd es /video/hd.
Configuración del balanceador de cargas con un mapa de URL básico (haz clic para ampliar).
Configuración del balanceador de cargas con un mapa de URL básico (haz clic para ampliar)

En este diagrama, se muestra la estructura de los objetos de configuración de balanceo de cargas y sus relaciones.

Para controlar qué servicios o depósitos de backend reciben solicitudes entrantes, usa los siguientes parámetros de configuración del mapa de URL:

  • Servicio de backend predeterminado o depósito de backend predeterminado. Cuando creas un mapa de URL, debes especificar un servicio o un bucket de backend predeterminado, pero no ambos. Este valor predeterminado representa el servicio o bucket de backend al que Google Cloud dirige las solicitudes de URL con cualquier nombre de host, a menos que exista una regla de host aplicable.

  • Regla de host (hostRules). Una regla de host dirige las solicitudes enviadas a uno o más nombres de host asociados a un solo comparador de ruta de acceso (pathMatchers). La parte del nombre de host de una URL coincide con exactitud con el conjunto de nombres de host configurados de la regla de host. En un host de asignación de URL y una regla de ruta de acceso, si omites el host, la regla coincide con cualquier host solicitado. Para dirigir las solicitudes de http://example.net/video/hd a un comparador de rutas de acceso, necesitas una sola regla de host que incluya, al menos, el nombre del host example.net. Esa misma regla de host también podría manejar solicitudes de otros nombres de host, pero los dirigiría al mismo comparador de rutas de acceso.

    Si necesitas dirigir solicitudes a diferentes comparadores de rutas de acceso, debes usar reglas de host diferentes. Dos reglas de host en un mapa de URL no pueden tener el mismo nombre de host.

    Es posible hacer coincidir todos los nombres de host si especificas el carácter comodín * en la regla de host. Por ejemplo, para las URL http://example.org, http://example.net/video/hd y http://example.com/audio, se puede hacer coincidir a los tres nombres de host example.org, example.net y example.com si se especifica * en la regla de host. También es posible hacer coincidir un nombre de host parcial mediante el carácter comodín *. Por ejemplo, una regla de host *.example.net coincide con ambos nombres de host, foo.example.net y bar.example.net.

    • Número de puerto. Los diferentes balanceadores de cargas HTTP(S) controlan los números de puerto de manera diferente. En el caso del balanceador de cargas HTTP(S) interno, puedes usar el parámetro Regla de host para especificar un número de puerto. Por ejemplo, para dirigir las solicitudes example.net al puerto 8080, establece la regla de host en example.net:8080. En el caso del balanceador de cargas HTTP(S) externo global (clásico), solo el nombre de host en la URL se considera cuando se hace coincidir una regla de host. Por ejemplo, las solicitudes example.net para el puerto 8080 y el puerto 80 coinciden con la regla de host example.net.
  • Comparador de rutas de acceso (pathMatchers). Un comparador de rutas de acceso es el parámetro de configuración al que hace referencia una regla de host. Define la relación entre la parte de la ruta de acceso de una URL y el servicio o bucket de backend que debe entregar la solicitud. Un comparador de rutas de acceso consta de dos elementos:

    • Servicio de backend predeterminado del comparador de rutas de acceso o depósito de backend predeterminado del comparador de rutas de acceso. Para cada comparador de rutas de acceso, debes especificar, al menos, un servicio o un bucket de backend predeterminado, pero no ambos. Este valor predeterminado representa el servicio o bucket de backend o al que Google Cloud dirige las URL cuyos nombres de host coinciden con una regla de host asociada a un comparador de rutas de acceso y cuyas rutas de URL no coinciden con ninguna regla de ruta de acceso en el comparador de rutas de acceso.

    • Reglas de ruta de acceso Para cada comparador de rutas de acceso, puedes especificar una o más reglas de ruta de acceso, que son pares clave-valor que mapean una ruta de URL a un solo servicio o bucket de backend. La siguiente sección contiene más información sobre cómo funcionan las reglas de ruta de acceso.

Orden de las operaciones

Para un nombre de host y una ruta de acceso en una URL solicitada, Google Cloud usa el siguiente procedimiento a fin de dirigir la solicitud al servicio o bucket de backend correcto, como se configuró en el mapa de URL:

  • Si el mapa de URL no contiene una regla de host para el nombre del host de la URL, Google Cloud dirige las solicitudes al servicio o al bucket de backend predeterminado del mapa de URL, según cuál definiste.

  • Si el mapa de URL contiene una regla de host que incluye el nombre del host de la URL, se consulta el comparador de rutas de acceso al que hace referencia esa regla de host:

    • Si el comparador de rutas de acceso contiene una regla de ruta que coincide con exactitud con la ruta de la URL, Google Cloud dirige las solicitudes al servicio o depósito de backend para esa regla de ruta.

    • Si el comparador de rutas de acceso no contiene una regla de ruta que coincide con exactitud con la ruta de la URL, pero contiene una regla de ruta que termina en /*, cuyo prefijo coincide con la sección más larga de la ruta de la URL, Google Cloud dirigirá las solicitudes al servicio o depósito de backend para esa regla de ruta. Por ejemplo, para el mapa de URL que contiene dos reglas del comparador de rutas de acceso /video/hd/movie1 y /video/hd/*, si la URL contiene la ruta de acceso exacta /video/hd/movie1, se compara con esa regla de ruta.

    • Si ninguna de las condiciones anteriores es verdadera, Google Cloud dirige las solicitudes al servicio o bucket de backend predeterminado del comparador de rutas de acceso, según el que hayas definido.

Restricciones del comparador de rutas

Los nombres de host, los comparadores de rutas de acceso y las reglas de ruta de acceso tienen restricciones.

Comodines, expresiones regulares y URL dinámicas en reglas de ruta de acceso

  • Una regla de ruta de acceso solo puede incluir un carácter comodín (*) después de un carácter de barra diagonal (/). Por ejemplo, /videos/* y /videos/hd/* son válidos para las reglas de ruta, pero /videos* y /videos/hd* no.

  • Las reglas de ruta de acceso no usan expresiones regulares ni coincidencias de substrings. Por ejemplo, las reglas de ruta de acceso para /videos/hd o /videos/hd/* no se aplican a una URL con la ruta de acceso /video/hd-abcd. Sin embargo, una regla de ruta de acceso para /video/* sí se aplica a esa ruta.

  • Los comparadores de rutas de acceso (y los mapas de URL en general) no ofrecen características que funcionen como las directivas LocationMatch de Apache. Si tienes una aplicación que genera rutas de acceso de URL dinámicas que tienen un prefijo común, como /videos/hd-abcd y /videos/hd-pqrs, y necesitas enviar solicitudes que se realizaron a esas rutas a servicios de backend diferentes, es posible que no puedas hacerlo con un mapa de URL. Para casos simples que contengan solo algunas posibles URL dinámicas, es posible que puedas crear un comparador de rutas de acceso con un conjunto limitado de reglas de ruta. Para casos más complejos, es necesario realizar coincidencias de expresiones regulares basadas en rutas de acceso en tus backends.

Relación entre el nombre de host y la regla de host

  • Un nombre de host solo puede hacer referencia a una única regla de host.

  • Una única regla de host puede procesar varios nombres de host.

La relación entre los nombres de host y las reglas de host (haz clic para ampliar)
La relación entre los nombres de host y las reglas de host (haz clic para ampliar)

Relación entre la regla de host y el comparador de rutas de acceso

  • Varias reglas de host pueden hacer referencia a un solo comparador de rutas de acceso.

  • Una regla de host solo puede hacer referencia a un único comparador de rutas de acceso.

En el siguiente diagrama, se ilustran estos puntos.

La relación entre las reglas de host y los comparadores de rutas de acceso (haz clic para ampliar)
La relación entre las reglas de host y los comparadores de rutas de acceso (haz clic para ampliar)

Relación entre la URL y el backend

  • Cada URL única se dirige a un solo servicio o bucket de backend. Por lo tanto, sucede lo siguiente:

    • Google Cloud usa la parte del nombre de host de una URL para seleccionar una única regla de host y el comparador de rutas de acceso al que hace referencia.

    • Cuando usas reglas de ruta de acceso en un comparador de rutas de acceso, no puedes crear más de una regla de ruta de acceso para la misma ruta de acceso. Por ejemplo, las solicitudes de /videos/hd no se pueden dirigir a más de un servicio o bucket de backend. Los servicios de backend pueden tener grupos de instancias de backend o grupos de extremos de red (NEG) de backend en diferentes zonas y regiones, y puedes crear depósitos de backend que usen clases Multi-Regional Storage.

    Para dirigir el tráfico de una URL única a varios servicios, puedes usar reglas de enrutamiento en lugar de reglas de ruta de acceso. Si configuras el comparador de rutas de acceso con reglas de enrutamiento para coincidencias de parámetros o encabezados, una URL única se puede dirigir a más de un servicio o bucket de backend, según el contenido de los encabezados o los parámetros de búsqueda en la URL.

    De manera similar, para los balanceadores de cargas HTTP(S) regionales y Traffic Director, los servicios de backend ponderados en las acciones de ruta pueden dirigir la misma URL a varios servicios o buckets de backend, según los pesos establecidos en el servicio de backend ponderado.

Protocolos y mapas de URL

Puede usar los mismos mapas de URL, reglas de host y comparadores de rutas de acceso para procesar las solicitudes HTTP y HTTPS que envían los clientes, siempre y cuando los proxies HTTP y HTTPS de destino hagan referencia al mapa de URL.

Mapa de URL más simple

El mapa de URL más simple solo tiene un servicio de backend predeterminado o un bucket de backend predeterminado. No contiene reglas de host ni comparadores de rutas de acceso. El servicio o el bucket de backend predeterminado (el que hayas definido) administra todas las URL solicitadas.

Si defines un servicio de backend predeterminado, Google Cloud dirige las solicitudes a sus grupos de instancias de backend o NEG de backend de acuerdo con la configuración del servicio de backend.

Mapa de URL sin reglas, excepto las predeterminadas (haz clic para ampliar)
Mapa de URL sin reglas, excepto las predeterminadas (haz clic para ampliar)

Ejemplo de flujo de trabajo de mapa de URL con un balanceador de cargas HTTP(S) externo

En el ejemplo siguiente, se ilustra el orden de las operaciones para un mapa de URL. En este ejemplo, se configura el mapa de URL para un balanceador de cargas de HTTP(S) externo. Por simplicidad conceptual, solo usa los servicios de backend. Sin embargo, puedes sustituirlos por depósitos de backend. Si deseas obtener información sobre cómo crear los demás componentes del balanceador de cargas de HTTP(S) externo, consulta Crea un balanceador de cargas de HTTP(S) externo.

Si deseas ver un ejemplo de cómo crear un mapa de URL del balanceador de cargas de HTTP(S) interno y otros componentes, consulta Preparación para una configuración del balanceo de cargas de HTTP(S) interno.

Cada servicio de backend que se analiza en el ejemplo siguiente cuenta con un esquema externo y usa el protocolo HTTP, HTTPS o HTTP/2.

  1. Crea un mapa de URL para el balanceador de cargas y especifica un servicio de backend predeterminado. En este ejemplo, se crea un mapa de URL llamado video-org-url-map que hace referencia a un servicio de backend existente llamado org-site.

    gcloud compute url-maps create video-org-url-map \
        --default-service=org-site
    
  2. Crea un comparador de rutas de acceso llamado video-matcher con las siguientes características:

    • El servicio de backend predeterminado es video-site, un servicio de backend existente.
    • Agrega reglas de ruta de acceso que dirigen las solicitudes para la ruta de URL /video/hd exacta o el prefijo de ruta de URL /video/hd/* a un servicio de backend existente llamado video-hd.
    • Agrega reglas de ruta de acceso que dirigen las solicitudes para la ruta de URL /video/sd exacta o el prefijo de ruta de URL /video/sd/* a un servicio de backend existente llamado video-sd.
    gcloud compute url-maps add-path-matcher video-org-url-map \
        --path-matcher-name=video-matcher \
        --default-service=video-site \
        --path-rules=/video/hd=video-hd,/video/hd/*=video-hd,/video/sd=video-sd,/video/sd/*=video-sd
    
  3. Crea una regla de host para el nombre de host example.net que hace referencia al comparador de rutas de acceso video-matcher.

    gcloud compute url-maps add-host-rule video-org-url-map \
        --hosts=example.net \
        --path-matcher-name=video-matcher
    

La URL video-org-url-map debería verse de esta forma:

gcloud compute url-maps describe video-org-url-map
creationTimestamp: '2021-03-05T13:34:15.833-08:00'
defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/org-site
fingerprint: mfyJIT7Zurs=
hostRules:
- hosts:
  - '*'
  pathMatcher: video-matcher
- hosts:
  - example.net
  pathMatcher: video-matcher
id: '8886405179645041976'
kind: compute#urlMap
name: video-org-url-map
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-site
  name: video-matcher
  pathRules:
  - paths:
    - /video/hd
    - /video/hd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-hd
  - paths:
    - /video/sd
    - /video/sd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-sd
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps/video-org-url-map

El mapa de URL video-org-url-map dirige las URL solicitadas a los backends de la siguiente manera.

Mapa de URL con una regla de ruta de acceso, comparadores de rutas de acceso y una regla de host (haz clic para ampliar)
Mapa de URL con una regla de ruta de acceso, comparadores de rutas de acceso y una regla de host (haz clic para ampliar)

En la siguiente tabla, se explica el procesamiento de solicitudes que se muestra en el diagrama anterior.

Nombre de host Rutas de URL Servicio de backend seleccionado Motivo de la selección
Nombre de host:
example.org y todos los demás nombres de host diferentes de
example.net
todas las rutas org-site El nombre de host no figura en ninguna regla de host del mapa de URL, por lo que la solicitud se dirige al servicio de backend predeterminado del mapa de URL.
Nombre de host
example.net
/video
/video/examples
video-site La solicitud se envía al servicio de backend predeterminado porque no hay una regla de ruta para /video/ o /video/*. La regla de host para example.net hace referencia a un comparador de rutas de acceso, pero ese comparador no tiene ninguna regla de ruta que se aplique a estas rutas de acceso.
Nombre de host
example.net
/video/hd
/video/hd/movie1
/video/hd/movies/movie2
Otras URL que comienzan con /video/hd/*
video-hd Una regla de host para example.net hace referencia a un comparador de rutas de acceso cuyas reglas de acceso envían solicitudes para rutas de URL que coinciden con exactitud con /video/hd o que comienzan con /video/hd/* al servicio de backend video-hd.
Nombre de host
example.net
/video/sd
/video/sd/show1
/video/sd/shows/show2
Otras URL que comienzan con /video/sd/*
video-sd Una regla de host para example.net hace referencia a un comparador de rutas de acceso cuyas reglas de acceso envían solicitudes para rutas de URL que coinciden con exactitud con /video/sd o que comienzan con /video/sd/* al servicio de backend video-sd.

Redireccionamientos de URL

El redireccionamiento de URL redirecciona a los visitantes de tu dominio de una URL a otra.

Un redireccionamiento de URL predeterminado no está condicionado a la coincidencia de ningún patrón en particular en la solicitud entrante. Por ejemplo, es posible que desees usar un redireccionamiento de URL predeterminado para redireccionar cualquier nombre de host a un nombre de host que elijas.

Existen varias formas de crear un redireccionamiento de la URL, como se describe en la siguiente tabla.

Método Configuration
Redireccionamiento predeterminado de URL del mapa de URL TopLevel defaultUrlRedirect
El redireccionamiento predeterminado de una URL del comparador de rutas de acceso pathMatchers[].defaultUrlRedirect[]
El redireccionamiento de URL de una regla de ruta de acceso de un comparador de rutas pathMatchers[].pathRules[].urlRedirect
El redireccionamiento de la URL de la regla de enrutamiento de un comparador de rutas pathMatchers[].routeRules[].urlRedirect

Dentro de un defaultUrlRedirect o urlRedirect, pathRedirect siempre funciona de la siguiente manera:

  • Toda la ruta de solicitud se reemplaza con la ruta de acceso que especifiques.

Dentro de un defaultUrlRedirect o urlRedirect, el funcionamiento de prefixRedirect depende de cómo lo uses:

  • Si usas un defaultUrlRedirect, prefixRedirect es, en efecto, un prefijo precedido por la ruta de acceso coincidente siempre es /.
  • Si usas un urlRedirect dentro de la regla de enrutamiento o la regla de ruta de un comparador de rutas de acceso, prefixRedirect es un reemplazo de prefijo según la coincidencia de la ruta de acceso solicitada como se define en la regla de ruta de acceso o la regla de enrutamiento.

Ejemplos de redireccionamientos

En la siguiente tabla, se proporcionan algunos ejemplos de configuraciones de redireccionamiento. En la columna de la derecha, se muestra la configuración de la API para un redireccionamiento de URL predeterminado.

Deseas Se logra mediante un redireccionamiento predeterminado de URL.
Redireccionamiento HTTP a HTTPS

Redireccionamiento
http://host.name/path
a
https://host.name/path

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
           
Redireccionamiento HTTP a HTTPS + Host

Redireccionamiento
http://any-host-name/path
a
https://www.example.com/path

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
          
Redireccionamiento HTTP a HTTPS + Host + Redireccionamiento de ruta de acceso completa

Redireccionamiento
http://any-host-name/path
a
https://www.example.com/newPath

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
              pathRedirect: "/newPath"
           
Redireccionamiento HTTP a HTTPS + Host + Prefijo

Redireccionamiento
http://any-host-name/originalPath
a
https://www.example.com/newPrefix/originalPath

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
              prefixRedirect: "/newPrefix"
            

En el siguiente fragmento parcial, se anota cada recurso de la API:

defaultUrlRedirect:
   redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
   httpsRedirect: True # True if you want https://, false if you want http://
   hostRedirect: "new-host-name.com" # Omit to keep the requested host
   pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
   prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
   stripQuery: False # True to omit everything in the URL after ?
   ...

¿Qué sigue?