Ich kämpfe seit geraumer Zeit mit einem Problem, das anscheinend noch nicht gemeldet wurde. Ich entschuldige mich für die ungewöhnliche Anzahl von beweglichen Teilen, werde aber versuchen, es kurz und bündig zu beschreiben.
Die TL;DR-Version lautet: Wenn ich einen Link in eine Nachricht einfüge, sendet das Ruby-Gem, das letztendlich den HTTP-GET-Request an diese URL stellt, um Einbettungsdaten zu suchen, eine HTTP-Anfrage, die von einigen HTTP-Proxys als nicht konform mit der Spezifikation betrachtet wird. Dies verhindert in einigen Fällen die Vorschau:
Die etwas längere Version ist folgende: Wir nutzen einen netten kleinen Dienst namens Gitbook.io für unsere Dokumentation. Gitbook ist eine gehostete Lösung und verwendet Cloudflare-Worker für interne Weiterleitungen auf ihrer Website. Zu diesen Cloudflare-Workern gehört die Verwendung der Node Fetch-API, um HTTP-Anfragen zu proxyen. Die Entwickler von Node Fetch sind EXTREM pedantisch in Bezug auf die Einhaltung der Spezifikation und lehnen jede GET-Anfrage ab, die einen HTTP-Body oder sogar einen Content-Length-Header enthält, selbst wenn dieser Header auf 0 gesetzt ist.
Und genau das passiert. Das Ruby-Gem, das die HTTP-Anfrage stellt, sendet einen
Content-Length: 0
Header, was die Node-Fetch-Proxy-Instanz extrem ärgert und dazu führt, dass die Anfrage vom Remote-Server abgelehnt wird. In verschiedenen Foren wurde viel darüber diskutiert, ob ein Request-Body bei einer GET-Anfrage oder sogar nur ein Content-Length-Header gemäß der HTTP-Spezifikation gültig ist. Ich habe kein Problem damit, aber das hat die Node-Fetch-Entwickler nicht davon abgehalten, jede eingereichte Issue zu schließen, in der sie gebeten wurden, eine solche Semantik zuzulassen.
Ich stecke leider in der Mitte fest:
- Das Node-Fetch-Projekt lehnt es ab, diese HTTP-Anfragen als gültig zu betrachten.
- Der Cloudflare-Support hilft mir nicht, weil ich keine Kontrolle über die betreffenden Node-basierten Worker habe.
- Der Gitbook-Support hilft mir nicht, weil er den Fetch-Entwicklern zustimmt (und ich bin mir nicht sicher, ob es ihnen wirklich wichtig ist).
- Und die HTTPrb-Bibliothek lehnt es ab, den Header zu entfernen, weil sie ihn für völlig gültig halten.
Das bedeutet, ich wende mich hiermit an euch und frage, ob es eine Möglichkeit gibt, die für Linkvorschauen verwendeten HTTP-GET-Anfragen so zu steuern oder zu ändern, dass sie einen akzeptablen Satz von HTTP-Headern enthalten, sodass Proxys, die extrem pedantische Bibliotheken wie Node Fetch verwenden, diese Anfragen nicht ablehnen?
Wenn ihr es ausprobieren möchtet, hier ist eine Beispiel-URL, die auf Gitbooks Servern gehostet wird und ihren Node-Fetch-basierten Cloudflare-Worker verwendet:
– aber das ist zumindest nicht Discourses Problem).
