Jak używać nagłówków Request-Response

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 AppMasterW 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 Allowedbutwymienia 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( triggeronClick w workflow przycisku), a tytuły etykiet są aktualizowane o te informacje(Label Update Properties).