Llevo un tiempo lidiando con un problema que, por lo que parece, aún no ha sido reportado. Me disculpo por la cantidad inusual de elementos involucrados, pero intentaré describirlo de manera concisa.
El TL;DR es que cuando pego un enlace en un mensaje, la Gem de Ruby que finalmente realiza la solicitud HTTP GET a esa URL para buscar datos de incrustación envía una solicitud HTTP que algunos proxies HTTP consideran inválida según la especificación. Esto impide que las vistas previas funcionen en algunos casos:
La versión un poco más larga es la siguiente. Utilizamos un servicio muy bueno llamado Gitbook.io para nuestra documentación. Gitbook es una solución alojada y utilizan Cloudflare workers para redirecciones internas en su sitio. Parte de esos workers de Cloudflare implica el uso de la API Node Fetch para proxy de solicitudes HTTP. Los desarrolladores de Node Fetch son EXTREMADAMENTE pedantes al seguir la especificación y rechazarán cualquier solicitud GET que tenga un cuerpo HTTP o incluso una cabecera Content-Length, aunque esa cabecera esté establecida en 0.
Y eso es exactamente lo que está ocurriendo. La Gem de Ruby que realiza la solicitud HTTP envía una cabecera de solicitud
Content-Length: 0
y esto enfurece enormemente al proxy de Node Fetch, lo que termina provocando que la solicitud sea rechazada por el servidor remoto. Ha habido mucho debate en diferentes foros sobre si un cuerpo de solicitud en una GET o simplemente una cabecera de longitud de contenido es válido según la especificación HTTP. A mí no me importa, pero eso no ha impedido que los desarrolladores de Node Fetch cierren cada problema que se ha abierto rogándoles que permitan tal semántica.
Desafortunadamente, me encuentro atrapado en medio de esto.
- El proyecto Node Fetch se niega a considerar estas solicitudes HTTP como válidas.
- El soporte de Cloudflare se niega a ayudarme porque no tengo control sobre los workers basados en Node en cuestión.
- El soporte de Gitbook se niega a ayudarme porque están de acuerdo con los desarrolladores de Fetch (y no estoy seguro de que realmente les importe).
- Y la biblioteca HTTPrb se niega a eliminar la cabecera porque consideran que es perfectamente válida.
Así que me queda publicar aquí preguntando si hay alguna forma de controlar o modificar las solicitudes HTTP GET realizadas para las vistas previas de enlaces, de modo que incluyan un conjunto aceptable de cabeceras HTTP para que los proxies que utilizan bibliotecas increíblemente pedantes como Node Fetch no rechacen estas solicitudes.
Si quieren intentarlo, aquí hay una URL de ejemplo alojada en los servidores de Gitbook que utiliza su worker de Cloudflare impulsado por Node Fetch.
Sin embargo, ha estado funcionando durante años.