13 Punkte von xguru 2024-09-18 | 7 Kommentare | Auf WhatsApp teilen
  • Eine neue HTTP-Methode namens QUERY wird vorgeschlagen
    • Eine Request-Methode, die Inhalte beim Request übertragen kann und dabei sicher sowie idempotent ist
    • Diese Methode kann verwendet werden, wenn die im Request zu übertragenden Daten zu groß sind, um in eine URI codiert zu werden
  • Wenn Query-Parameter mehrere KB groß sind, setzen viele Implementierungen Grenzen
    • Oft ist diese Grenze vor dem Request nicht im Voraus bekannt, und da codiert werden muss, ist das ineffizient
  • Deshalb verwenden viele Implementierungen POST statt GET, um Queries auszuführen
    • Ohne konkretes Wissen über den Server lässt sich jedoch nicht erkennen, ob dies sicher und idempotent ist, wodurch ähnliche grundlegende Einschränkungen wie bei GET bestehen
  • Die Methode QUERY bietet eine Lösung, um die Lücke zwischen der Verwendung von GET und POST zu schließen
    • Wie bei POST werden Eingaben für Query-Operationen im Inhalt des Requests und nicht als Teil der Request-URI übermittelt
    • Anders als bei POST ist diese Methode jedoch ausdrücklich sicher und idempotent, sodass Funktionen wie Caching und automatische Wiederholungen möglich sind

Request

QUERY /contacts HTTP/1.1  
Host: example.org  
Content-Type: example/query  
Accept: text/csv  
  
select surname, givenname, email limit 10  

Response

HTTP/1.1 200 OK  
Content-Type: text/csv  
Content-Location: /contacts/responses/42  
Location: /contacts/queries/17  
  
surname, givenname, email  
Smith, John, john.smith@example.org  
Jones, Sally, sally.jones@example.com  
Dubois, Camille, camille.dubois@example.net  

7 Kommentare

 
regentag 2024-09-19

Ich verstehe nicht, warum man das dem Protokoll hinzufügen muss.
Gibt es wirklich so viele Szenarien, in denen Query-Parameter mehrere KB überschreiten?

 
savvykang 2024-09-19

https://www.baeldung.com/cs/http-get-with-body
Es wirkt so, als würde man wegen der HTTP-Spezifikation, die den Lesern Raum für eigene Interpretationen lässt und sich zudem inkonsistent verändert hat, gleich versuchen, eine ganz neue Methode zu schaffen.

 
nemorize 2024-09-18

GET mit Request-Body

 
beoks 2024-09-19

Einige Client-Bibliotheken bieten beim Senden von GET-Anfragen gar keine Möglichkeit, einen Request-Body mitzusenden; dafür könnte das eine Alternative sein.

 
nemorize 2024-09-20

Aus Sicht der Bibliotheksimplementierung ist das eher ein Vorschlag für eine Standardänderung, den man noch weniger braucht, oder nicht?

Laut Standardspezifikation darf GET keinen Request-Body haben, aber die Bibliothek übergibt willkürlich einen Request-Body ...
Wenn das so ist, wäre es dann nicht genauso gut möglich, einfach auf Bibliotheksebene eine Custom-Methode zu implementieren?

Es ist zwar schwer, die Notwendigkeit komplett zu verneinen, aber im Vergleich zu PUT, PATCH und DELETE, die mit dem Übergang von HTTP 1.0 zu 1.1 entstanden sind, scheint mir das weniger überzeugend.

 
babadudu 2024-09-23

https://www.rfc-editor.org/rfc/rfc9110.html#name-method-definitions

https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET

https://stackoverflow.com/questions/978061/http-get-with-request-body

https://elastic.co/guide/en/…

  1. In der Standard-Spezifikation wird beim GET-Methodenteil der Body nicht ausdrücklich beschrieben, aber es wurde nie gesagt, dass man keinen verwenden darf.

  2. Da es Server-Frameworks gibt, die einen Body bei der GET-Methode nicht verarbeiten, empfiehlt MDN, bei der GET-Methode keinen Body zu verwenden.

  3. Elasticsearch unterstützt einen Body bei der GET-Methode.

 
vwjdalsgkv 2024-09-20

Ich denke, es braucht noch mehr Überlegung, ob die Spezifikation wirklich wegen der Implementierung einer Bibliothek geändert werden sollte.