Prawie wszystko, co widzisz w swojej przeglądarce, jest przesyłane do Twojego komputera za pomocą protokołu HTTP. Na przykład, kiedy otworzyłeś stronę tego artykułu, Twoja przeglądarka wysłała wiele żądań HTTP (Request) i otrzymała wiele odpowiedzi (Response).
HTTP nagłówki ( Header) są ważną częścią tych HTTP żądania i odpowiedzi, przekazują informacje o przeglądarce klienta, żądanej stronie, serwerze itp.
W tym tutorialu pokażemy, jak uzyskać potrzebne informacje z Request Headers. Ten tutorial prowadzi do tego, jak uzyskać interesujące nas informacje z nagłówków żądania ( Request Headers) i ustawić określone wartości w niezbędnych nagłówkach odpowiedzi ( Response Headers).
Najprostszym sposobem na uzyskanie informacji o zawartości Request Headers jest wykonanie żądania w opublikowanej aplikacji.
- Przejdź do narzędzia deweloperskiego ( F12).
- Przejdź do Networks zakładkę.
- Wybieranie przesłanego żądania z listy.
- Przejdź do Headers i znajdź zakładkę Request Headers sekcję.
Jak używać AppMaster do interakcji z nagłówkami Request-Response
W AppMaster W projektancie backendu możesz uzyskać informacje o nagłówku żądania, jeśli jego nazwa jest określona w bloku Get Request Headers bloku procesu biznesowego.
- Name [ string] - Nazwa nagłówka;
- Value [ string] - Wartość nagłówka;
Aby dodać niestandardowy Header w odpowiedzi - blok Set Response Header używany jest blok the.
- Name [string] - Nazwa nagłówka;
- Value [ string] - wartość nagłówka;
Istnieje wiele Request Headers istnieje, ale kilka z nich opisujemy poniżej (informacje pochodzą z https://www.w3.org/Protocols/HTTP/HTRQ_Headers.html):
-
From - W formacie poczty internetowej podaje nazwę użytkownika żądającego. Pole to może być wykorzystywane do celów logowania oraz jako niezabezpieczona forma ochrony dostępu. Interpretacja tego pola jest taka, że żądanie jest wykonywane w imieniu podanej osoby, która przyjmuje odpowiedzialność za wykonaną metodę. Adres poczty internetowej w tym polu nie musi odpowiadać hostowi internetowemu, który wydał żądanie. (Na przykład, gdy żądanie jest przepuszczane przez bramę, wtedy należy użyć oryginalnego adresu wystawcy). Adres pocztowy powinien, w miarę możliwości, być prawidłowym adresem pocztowym, niezależnie od tego, czy jest to w rzeczywistości adres poczty internetowej, czy reprezentacja adresu poczty internetowej w jakimś innym systemie pocztowym.
-
Accept - Pole to zawiera oddzieloną średnikami listę schematów reprezentacji ( Content-Type metainformation values), które będą akceptowane w odpowiedzi na to żądanie. Podany zestaw może oczywiście różnić się w zależności od żądania od tego samego użytkownika.
Przykład:
Accept: text/plain, text/html
Accept: text/x-dvi; q=.8; mxb=100000; mxt=5.0, text/x-c
-
Accept-Encoding- Podobne do Accept, ale wymienia typy Content-Encoding, które są akceptowane w odpowiedzi.
Przykład:
Accept-Encoding: x-compress; x-zip
-
Referer- To opcjonalne pole nagłówka pozwala klientowi określić, na korzyść serwera, adres ( URI ) dokumentu (lub elementu w ramach dokumentu), z którego uzyskano URI w żądaniu. Pozwala to serwerowi na generowanie list linków zwrotnych do dokumentów, w celu zainteresowania, logowania itp. Umożliwia śledzenie złych linków w celu ich utrzymania. Jeśli podany jest częściowy URI, to powinien być parsowany względem URI obiektu żądania.
Przykład:
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
-
Authorization- Jeśli ta linia jest obecna, zawiera informacje o autoryzacji. Format to To Be Specified (TBS). Format tego pola jest w formie rozszerzalnej. Pierwsze słowo to specyfikacja używanego systemu autoryzacji.
Przykład:
Authorization: Bearer BtHKEsVs5mNNtNf7UWoVwjJzFqLOzucA
-
Accept-Language- Podobne do Accept, ale wymienia wartości Language, które są preferowane w odpowiedzi. Odpowiedź w nieokreślonym języku nie jest nielegalna.
-
User-Agent- Ta linia, jeśli jest obecna, podaje program używany przez oryginalnego klienta. Służy to do celów statystycznych i śledzenia naruszeń protokołu. Powinien być dołączony. Pierwsze słowo ograniczone białą spacją musi być nazwą produktu oprogramowania, z opcjonalnym ukośnikiem i oznaczeniem wersji. Inne produkty, które stanowią część agenta użytkownika, mogą być umieszczone jako oddzielne słowa.
Przykład:
User-Agent: LII-Cello/1.0 libwww/2.5
Response Headers przykłady:
- Allowed- Wymienia zestaw żądań, które żądający użytkownik może wydać dla tego adresu URL. Jeśli ta linia nagłówka jest pominięta, domyślne dozwolone metody to "GET HEAD"
- Public- Jak Allowedbut wymienia te żądania, których każdy może użyć. Jeśli pominięty, domyślnie jest "GET" tylko.
- Content-Length- Implikuje, że ciało jest binarne i powinno być odczytane bezpośrednio z łącza komunikacyjnego, bez parsowania linii itp. Gdy dane są częścią żądania, zapobiega ucieczce i deeskalacji sekwencji zakończenia.
- Content-Encoding- Określa zastosowany mechamizm kodowania. Obecnie w użyciu są tylko x-compress i x-gzip.
- Content-Type- określa typ dokumentu.
- Content-Length- Oznacza, że ciało jest binarne i powinno być odczytane bezpośrednio z łącza komunikacyjnego, bez parsowania linii itp. Gdy dane są częścią żądania, uniemożliwia eskploatację i deeskploatację sekwencji zakończenia.
- Last-Modified- Ostatni raz obiekt został zmodyfikowany, czyli data tej wersji, jeśli dokument jest "żywym dokumentem".
Zobaczmy przykład uzyskania IP użytkownika i jego wartości Cookie z nagłówków Request.
Do uzyskania IP użytkownika użyto x-real-ip. Nagłówki Request Cookie dostarczają informacji o tokenach Cookie.
BP wygląda tak:
W następnym kroku należy stworzyć endpoint dla tego BP
UI wygląda następująco:
Ostatecznie wynik jest pokazany poniżej. Użytkownik otrzymuje informacje z nagłówków po kliknięciu przycisku ( trigger onClick w workflow przycisku), a tytuły etykiet są aktualizowane o te informacje (Label Update Properties).
