HTTP GET z treścią żądania

Tworzę nową usługę RESTful dla naszej aplikacji.

Podczas wykonywania GET na niektórych obiektach klienci mogą żądać zawartości tego obiektu. Jeśli chcą dodać niektóre parametry (na przykład sortując listę), mogą dodać te parametry w ciągu zapytania.

Alternatywnie chcę, aby ludzie mogli określić te parametry w treści żądania. HTTP / 1.1 nie wydaje się tego wyraźnie zabraniać. Pozwoli im to określić więcej informacji, może ułatwić określenie złożonych żądań XML.

Moje pytania:

• Czy to w ogóle dobry pomysł?
• Czy klienci HTTP będą mieli problemy z używaniem treści żądania w ramach żądania GET?

http://tools.ietf.org/html/rfc2616

Komentarz Roya Fieldinga dotyczący włączenia ciała z prośbą GET .

Tak. Innymi słowy, każda wiadomość z żądaniem HTTP może zawierać treść wiadomości, a zatem musi analizować wiadomości w tym celu. Semantyka serwera dla GET jest jednak ograniczona w taki sposób, że treść, jeśli istnieje, nie ma znaczenia semantycznego dla żądania. Wymagania dotyczące analizowania są oddzielone od wymagań dotyczących semantyki metody.

Tak, tak, możesz wysłać ciało za pomocą GET i nie, nigdy nie jest to przydatne.

Jest to część warstwowego projektu HTTP / 1.1, który ponownie stanie się przejrzysty po podzieleniu specyfikacji (praca w toku).

.... Roy

Tak, możesz wysłać treść żądania za pomocą GET, ale nie powinno to mieć żadnego znaczenia. Jeśli nadasz mu znaczenie, analizując go na serwerze i zmieniając odpowiedź w oparciu o jego zawartość , wówczas ignorujesz to zalecenie w specyfikacji HTTP / 1.1, sekcja 4.3 :

[...] jeśli metoda żądania nie obejmuje zdefiniowanej semantyki dla ciała encji, wówczas treść komunikatu POWINNA zostać zignorowana podczas obsługi żądania.

I opis metody GET w specyfikacji HTTP / 1.1, sekcja 9.3 :

Metoda GET oznacza pobieranie wszelkich informacji ([...]) zidentyfikowanych przez URI żądania.

który stwierdza, że ​​ciało żądania nie jest częścią identyfikacji zasobu w żądaniu GET, tylko identyfikator URI żądania.

Aktualizacja RFC2616 określany jako „specyfikacja HTTP / 1.1” jest już nieaktualny. W 2014 r. Został zastąpiony przez RFC 7230-7237. Cytuj „treść wiadomości POWINNA zostać zignorowana podczas obsługi żądania” została usunięta. Teraz jest to po prostu „Żądanie ramkowania wiadomości jest niezależne od semantyki metody, nawet jeśli metoda nie definiuje żadnego zastosowania dla treści wiadomości” Drugi cytat „Metoda GET oznacza pobieranie wszelkich informacji ... zidentyfikowanych przez URI żądania” został usunięty. - Z komentarza

Chociaż możesz to zrobić, o ile nie jest to wyraźnie wykluczone w specyfikacji HTTP, sugerowałbym unikanie tego tylko dlatego, że ludzie nie oczekują, że coś będzie działać w ten sposób. Łańcuch żądań HTTP składa się z wielu etapów i chociaż „w większości” są one zgodne ze specyfikacją HTTP, jedyną gwarancją jest to, że będą się zachowywać tak, jak zwykle używane są w przeglądarkach internetowych. (Myślę o takich rzeczach, jak przezroczyste proxy, akceleratory, zestawy narzędzi A / V itp.)

Taki jest duch zasady solidności z grubsza „bądź liberalny w tym, co akceptujesz, a konserwatywny w tym, co wysyłasz”, nie chcesz przekraczać granic specyfikacji bez uzasadnionego powodu.

Jeśli jednak masz dobry powód, idź do niego.

Prawdopodobnie napotkasz problemy, jeśli kiedykolwiek spróbujesz skorzystać z buforowania. Serwery proxy nie będą szukać w treści GET, aby sprawdzić, czy parametry mają wpływ na odpowiedź.

Ani restclient, ani konsola REST nie obsługują tego, ale curl tak.

Specyfikacja HTTP mówi w sekcji 4.3

Ciało komunikatu NIE MOŻE być zawarte w żądaniu, jeśli specyfikacja metody żądania (sekcja 5.1.1) nie pozwala na wysyłanie ciała jednostki w żądaniach.

Sekcja 5.1.1 przekierowuje nas do sekcji 9.x dla różnych metod. Żaden z nich wyraźnie nie zabrania dołączania treści wiadomości. Jednak...

Sekcja 5.2 mówi

Dokładny zasób zidentyfikowany na podstawie żądania internetowego jest określany poprzez sprawdzenie zarówno URI żądania, jak i pola nagłówka Host.

a sekcja 9.3 mówi

Metoda GET oznacza pobieranie wszelkich informacji (w formie encji) identyfikowanych przez identyfikator URI żądania.

Które razem sugerują, że podczas przetwarzania żądania GET serwer nie musi sprawdzać niczego innego niż pole URI żądania i pole nagłówka Host.

Podsumowując, specyfikacja HTTP nie uniemożliwia wysłania treści wiadomości za pomocą GET, ale istnieje wystarczająca dwuznaczność, która nie zaskoczyłaby mnie, gdyby nie była obsługiwana przez wszystkie serwery.

Elasticsearch akceptuje żądania GET z treścią. Wydaje się nawet, że jest to preferowany sposób: Przewodnik po Elasticsearch

Niektóre biblioteki klienta (np. Sterownik Ruby) mogą rejestrować komendę cry na standardowym wyjściu w trybie programowania i korzysta z tej składni w szerokim zakresie.

To, co próbujesz osiągnąć, zostało zrobione przez długi czas przy użyciu znacznie popularniejszej metody, która nie polega na użyciu ładunku z GET.

Możesz po prostu zbudować swój konkretny mediaty wyszukiwania, lub jeśli chcesz być bardziej RESTful, użyj czegoś takiego jak OpenSearch i WYŚLIJ żądanie do identyfikatora URI, który polecił serwer, powiedz / szukaj. Serwer może następnie wygenerować wynik wyszukiwania lub zbudować końcowy identyfikator URI i przekierować za pomocą 303.

Ma to tę zaletę, że postępuje zgodnie z tradycyjną metodą PRG, pomaga buforować wyniki pośrednikom w pamięci podręcznej itp.

To powiedziawszy, URI są i tak kodowane dla wszystkiego, co nie jest ASCII, podobnie jak application / x-www-form-urlencoded i multipart / form-data. Zalecam użycie tego zamiast tworzenia kolejnego niestandardowego formatu JSON, jeśli masz zamiar obsługiwać scenariusze ReSTful.

Możesz albo wysłać GET z ciałem, albo wysłać POST i zrezygnować z RESTish religijności (nie jest tak źle, 5 lat temu był tylko jeden członek tej wiary - jego komentarze powyżej).

Nie są to również świetne decyzje, ale wysłanie treści GET może zapobiec problemom niektórych klientów - i niektórych serwerów.

Wykonanie testu POST może napotkać przeszkody w niektórych ramach RESTish.

Julian Reschke zasugerował powyżej, używając niestandardowego nagłówka HTTP, takiego jak „SZUKAJ”, co może być eleganckim rozwiązaniem, z tym wyjątkiem, że jest jeszcze mniej prawdopodobne, że będzie obsługiwane.

Najbardziej wydajne może być wyświetlenie listy klientów, którzy mogą i nie mogą wykonać każdego z powyższych.

Klienci, którzy nie mogą wysłać GET z ciałem (o czym wiem):

• XmlHTTPRequest Fiddler

Klienci, którzy mogą wysłać GET z treścią:

• większość przeglądarek

Serwery i biblioteki, które mogą pobrać ciało z GET:

• Apacz
• PHP

Serwery (i serwery proxy), które usuwają ciało z GET:

• ?

Zadałem to pytanie IGF HTTP WG. Komentarz Roy'a Fieldinga (autora dokumentu http / 1.1 w 1998 r.) Był taki

„... implementacja zostałaby zepsuta, aby zrobić coś innego niż parsowanie i odrzucenie tego ciała, jeśli zostanie otrzymane”

RFC 7213 (HTTPbis) stwierdza:

„Ładunek w komunikacie żądania GET nie ma zdefiniowanej semantyki;”

Teraz wydaje się jasne, że intencją było, aby znaczenie semantyczne w treściach żądania GET było zabronione, co oznacza, że ​​treść żądania nie może być użyta do wpłynięcia na wynik.

Istnieją serwery proxy, które na pewno złamią twoją prośbę na różne sposoby, jeśli dodasz ciało do GET.

Podsumowując, nie rób tego.

Który serwer to zignoruje? - fijiaaron 30 sierpnia 2012 o 21:27

Google na przykład ma gorsze wyniki niż ignorowanie, uzna to za błąd !

Wypróbuj sam z prostym netcat:

$ netcat www.google.com 80
GET / HTTP/1.1
Host: www.google.com
Content-length: 6

1234

(po zawartości 1234 następuje CR-LF, czyli w sumie 6 bajtów)

a otrzymasz:

HTTP/1.1 400 Bad Request
Server: GFE/2.0
(....)
Error 400 (Bad Request)
400. That’s an error.
Your client has issued a malformed or illegal request. That’s all we know.

Dostajesz także 400 Bad Request od Bing, Apple itp. ... które są obsługiwane przez AkamaiGhost.

Dlatego nie zalecałbym używania żądań GET z jednostką treści.

Z RFC 2616, sekcja 4.3 , „Treść wiadomości”:

Serwer POWINIEN czytać i przekazywać treść wiadomości na każde żądanie; jeśli metoda żądania nie obejmuje zdefiniowanej semantyki dla ciała encji, wówczas treść komunikatu POWINNA zostać zignorowana podczas obsługi żądania.

Oznacza to, że serwery powinny zawsze odczytywać wszelkie udostępnione treści żądania z sieci (sprawdzać Długość treści lub odczytywać fragmenty itp.). Ponadto pełnomocnicy powinni przekazywać wszelkie otrzymane przez siebie takie organy wniosku. Następnie, jeśli RFC definiuje semantykę dla treści dla danej metody, serwer może faktycznie użyć treści żądania do wygenerowania odpowiedzi. Jeśli jednak RFC nie definiuje semantyki dla treści, serwer powinien ją zignorować.

Jest to zgodne z cytatem z Fielding powyżej.

Sekcja 9.3 , „GET”, opisuje semantykę metody GET i nie wspomina o treściach żądań. Dlatego serwer powinien zignorować wszelkie treści żądania otrzymane na żądanie GET.

Według XMLHttpRequest nie jest poprawny. Od standardu :

4.5.6 send()Metoda

client . send([body = null])

Inicjuje żądanie. Opcjonalny argument zapewnia treść żądania. Argument jest ignorowany, jeśli metodą żądania jest GETlub HEAD.

Zgłasza InvalidStateErrorwyjątek, jeśli którykolwiek stan nie jest otwarty lub send()flaga jest ustawiona.

Metoda musi uruchamiać kroki:send(body)

1. Jeśli stan nie jest otwarty , wyrzuć InvalidStateErrorwyjątek.
2. Jeśli send()flaga jest ustawiona, wyrzuć InvalidStateErrorwyjątek.
3. Jeśli metodą żądania jest GETlub HEAD, ustaw wartość body na null.
4. Jeśli ciało jest puste, przejdź do następnego kroku.

Chociaż nie sądzę, że powinno tak być, ponieważ żądanie GET może wymagać dużej zawartości treści.

Jeśli więc polegasz na XMLHttpRequest przeglądarki, prawdopodobnie nie będzie działać.

Jeśli naprawdę chcesz wysłać buforowalną treść JSON / XML do aplikacji internetowej, jedynym rozsądnym miejscem na umieszczenie danych jest ciąg zapytania zakodowany za pomocą RFC4648: kodowanie Base 64 z URL i bezpiecznym alfabetem nazwy pliku . Oczywiście możesz po prostu urlencode JSON i umieścić jest w wartości parametru param URL, ale Base64 daje mniejszy wynik. Pamiętaj, że istnieją ograniczenia rozmiaru adresu URL, zobacz Jaka jest maksymalna długość adresu URL w różnych przeglądarkach? .

Możesz myśleć, że =znak dopełniania Base64 może być zły dla wartości param adresu URL, jednak wydaje się, że nie - patrz ta dyskusja: http://mail.python.org/pipermail/python-bugs-list/2007-Feburn/037195.html . Nie należy jednak umieszczać zakodowanych danych bez nazwy parametru, ponieważ zakodowany ciąg z dopełnianiem będzie interpretowany jako klucz parametru z pustą wartością. Użyłbym czegoś takiego ?_b64=<encodeddata>.

Nie radziłbym tego, jest to sprzeczne ze standardowymi praktykami i nie oferuje tyle w zamian. Chcesz zachować treść, a nie opcje.

Co z niezgodnymi nagłówkami zakodowanymi w base64? „SOMETHINGAPP-PARAMS: sdfSD45fdg45 / aS”

Ograniczenia długości hm. Czy nie potrafisz rozróżnić znaczeń w procedurze POST? Jeśli chcesz prostych parametrów, takich jak sortowanie, nie rozumiem, dlaczego byłby to problem. Myślę, że martwisz się pewnością.

Jestem zdenerwowany tym, że REST, ponieważ protokół nie obsługuje OOP, a Getmetoda jest dowodem. Jako rozwiązanie możesz serializować DTO do JSON, a następnie utworzyć ciąg zapytania. Po stronie serwera możesz przekształcić ciąg zapytania do DTO.

Spójrz na:

• Projektowanie oparte na wiadomościach w ServiceStack
• Budowanie usług WWW opartych na wiadomościach RESTful z WCF

Podejście oparte na wiadomościach może pomóc w rozwiązaniu problemu Ograniczenie metody. Będziesz mógł wysłać dowolne DTO jak w treści żądania

Struktura serwisu internetowego Nelibur zapewnia funkcjonalność, z której można korzystać

var client = new JsonServiceClient(Settings.Default.ServiceAddress);
var request = new GetClientRequest
    {
        Id = new Guid("2217239b0e-b35b-4d32-95c7-5db43e2bd573")
    };
var response = client.Get<GetClientRequest, ClientResponse>(request);

as you can see, the GetClientRequest was encoded to the following query string

http://localhost/clients/GetWithResponse?type=GetClientRequest&data=%7B%22Id%22:%2217239b0e-b35b-4d32-95c7-5db43e2bd573%22%7D

Na przykład działa z Curl, Apache i PHP.

Plik PHP:

<?php
echo $_SERVER['REQUEST_METHOD'] . PHP_EOL;
echo file_get_contents('php://input') . PHP_EOL;

Polecenie konsoli:

$ curl -X GET -H "Content-Type: application/json" -d '{"the": "body"}' 'http://localhost/test/get.php'

Wynik:

GET
{"the": "body"}

IMHO możesz po prostu wysłać JSONzakodowane (tj. encodeURIComponent) W URLten sposób, aby nie naruszać HTTPspecyfikacji i dostać się JSONna serwer.

Masz listę opcji, które są znacznie lepsze niż używanie treści żądania z GET.

Załóżmy, że masz kategorie i elementy dla każdej kategorii. Oba mają być identyfikowane przez id („catid” / „itemid” na potrzeby tego przykładu). Chcesz sortować według innego parametru „sortuj” w określonym „porządku”. Chcesz przekazać parametry „sortby” i „porządek”:

Możesz:

1. Użyj ciągów zapytań, np example.com/category/{catid}/item/{itemid}?sortby=itemname&order=asc
2. Użyj mod_rewrite (lub podobnego) dla ścieżek: example.com/category/{catid}/item/{itemid}/{sortby}/{order}
3. Użyj poszczególnych nagłówków HTTP przekazywanych z żądaniem
4. Użyj innej metody, np. POST, aby pobrać zasób.

Wszystkie mają swoje wady, ale są znacznie lepsze niż używanie GET z ciałem.

Nawet jeśli popularne narzędzie tego używa, jak często cytowano na tej stronie, myślę, że nadal jest to dość zły pomysł, ponieważ jest zbyt egzotyczny, mimo że nie zabrania tego specyfikacja.

Wiele pośrednich infrastruktur może po prostu odrzucić takie żądania.

Poprzez przykład zapomnieć o korzystaniu z niektórych dostępnych CDN przed swojej stronie internetowej, jak ten jeden :

Jeśli GETżądanie przeglądarki zawiera treść, CloudFront zwraca do przeglądarki kod stanu HTTP 403 (Zabroniony).

I tak, biblioteki klienta mogą również nie obsługiwać wysyłania takich żądań, jak opisano w tym komentarzu .

Korzystam z RestTemplate frameworka Spring w moim programie klienckim i po stronie serwera zdefiniowałem żądanie GET z treścią Json. Mój główny cel jest taki sam jak twój: gdy żądanie ma wiele parametrów, umieszczenie ich w ciele wydaje się bardziej uporządkowane niż umieszczenie ich w przedłużonym ciągu URI. Tak?

Ale niestety to nie działa! Po stronie serwera zgłoszono następujący wyjątek:

org.springframework.http.converter.HttpMessageNotReadableException: Brak wymaganej treści żądania ...

Ale jestem prawie pewien, że treść mojego kodu klienta została poprawnie dostarczona, więc co jest nie tak?

Prześledziłem metodę RestTemplate.exchange () i znalazłem:

// SimpleClientHttpRequestFactory.class
public class SimpleClientHttpRequestFactory implements ClientHttpRequestFactory, AsyncClientHttpRequestFactory {
    ...
    protected void prepareConnection(HttpURLConnection connection, String httpMethod) throws IOException {
        ...
        if (!"POST".equals(httpMethod) && !"PUT".equals(httpMethod) && !"PATCH".equals(httpMethod) && !"DELETE".equals(httpMethod)) {
            connection.setDoOutput(false);
        } else {
            connection.setDoOutput(true);
        }
        ...
    }
}

// SimpleBufferingClientHttpRequest.class
final class SimpleBufferingClientHttpRequest extends AbstractBufferingClientHttpRequest {
    ...
    protected ClientHttpResponse executeInternal(HttpHeaders headers, byte[] bufferedOutput) throws IOException {
        ...
        if (this.connection.getDoOutput() && this.outputStreaming) {
            this.connection.setFixedLengthStreamingMode(bufferedOutput.length);
        }

        this.connection.connect();
        if (this.connection.getDoOutput()) {
            FileCopyUtils.copy(bufferedOutput, this.connection.getOutputStream());
        } else {
            this.connection.getResponseCode();
        }
        ...
    }
}

Zauważ, że w metodzie executeInternal () argument wejściowy „bufferedOutput” zawiera treść komunikatu dostarczoną przez mój kod. Widziałem to przez debugger.

Jednak z powodu preparConnection () funkcja getDoOutput () w executeInternal () zawsze zwraca false, co z kolei powoduje całkowite zignorowanie bufferedOutput! Nie jest kopiowany do strumienia wyjściowego.

W związku z tym mój program serwera nie otrzymał treści wiadomości i zgłosił ten wyjątek.

To jest przykład RestTemplate frameworka Spring. Chodzi o to, że nawet jeśli treść komunikatu nie jest już zabroniona przez specyfikację HTTP, niektóre biblioteki lub struktury klienta lub serwera mogą nadal być zgodne ze starą specyfikacją i odrzucić treść wiadomości z żądania GET.