Żądania HTTP - wprowadzenie

30 december 2021
Jakub Rojek Jakub Rojek
Zdjęcie autorstwa Caspar Camille Rubin na Unsplash (https://unsplash.com/photos/89xuP-XmyrA)
Categories: IT fundamentals, Web

Mimo że od momentu, kiedy Internet zaczął nas otaczać ze wszystkich stron i nawet urządzenia AGD są z nim połączone, minęło już sporo czasu, nadal dla wielu osób podstawowe koncepcje związane z łączeniem się ze światem są nieznane. Powiedziałbym nawet, że jest to coraz bardziej nasilone zjawisko - sieć WWW jest tak powszechna, że niektórzy wręcz zapominają (co pokazały awarie w 2021 roku), że to ona jest podstawą do działania serwisów społecznościowych czy innych ulubionych stron internetowych. I tak - Internet nie jest tym samym, czym sieć WWW. Dzisiaj będziemy pisać głównie o tym drugi.

Dlatego przed Wami kolejny artykuł, który traktuje o podstawach w tej dziedzinie i wierzę, że przyda się on wielu osobom - zarówno nieinformatykom, którzy są ciekawi świata, jak i osobom, które dopiero zaczynają swoją przygodę z poważnym IT. Opiszemy sobie dzisiaj ogólnie, czym są żądania HTTP i jakie mogą być. Jednak zanim przejdziemy do samych żądań, musimy wyjaśnić inną, jeszcze bardziej podstawową kwestię.

Czym jest HTTP i czym się różni od HTTPS?

HTTP (lub Hypertext Transfer Protocol) to protokół, który jest wykorzystywany w sieci WWW (ang. World Wide Web) do przesyłania informacji o stronach bądź - bardziej ogólnie - zasobach sieci. Krótko mówiąc i nieco upraszczając - aby dostać się do zawartości sieci WWW, musimy użyć HTTP, do czego z kolei służą nam przeglądarki internetowe (np. Google Chrome, Mozilla Firefox czy Safari). Domyślnym portem (a więc taką "bramką wejściową"), pod którym komunikacja jest możliwa, jest 80.

Jest to protokół, który opiera się na żądaniach i odpowiedziach. Te pierwsze są wysyłane od użytkownika do serwera ze stroną i składają się zwykle z:

  • URL (adresu internetowego, pod którym zlokalizowany jest zasób, np. strona lub zdjęcie)
  • parametrów lub zawartości (ciała) żądania
  • nagłówków

Natomiast odpowiedź jest kierowana od serwera do pytającego użytkownika i zawiera:

  • kod odpowiedzi (jeśli wszystko jest w porządku, to zawiera się on pomiędzy 200 a 299)
  • sam zasób (np. treść strony internetowej)
  • nagłówki

Przeglądarki internetowe służą właśnie do tego, aby w odpowiedni sposób wysyłać te żądania i interpretować to, co zwracają serwery, aby na końcu wyświetlić upragnione dane użytkownikowi. Na protokole HTTP opierają się też REST-owe API, a w ten sposób możemy pobierać dane w sposób tekstowy.

Jeżeli do rozwinięcia Hypertext Transfer Protocol dodamy jeszcze "Secure", to dostaniemy HTTPS, czyli nic innego, jak protokół HTTP wzbogacony o szyfrowanie komunikacji i działający domyślnie pod portem 443. Jest to rzecz praktycznie niezbędna w dzisiejszych czasach, jeśli chcemy być poważnie traktowani zarówno przez użytkowników, klientów, jak i nawet wyszukiwarki internetowe (np. Google). Oczywiście, strony działające pod zwykłym HTTP nadal się zdarzają, ale służą albo celom wewnętrznym, albo wersjom testowym, albo zwyczajnie nie prezentują wartościowych informacji, które chcielibyśmy szyfrować. Tym niemniej, warto starać się o HTTPS dla wszystkich stron udostępnianych w sieci, a gdzieniegdzie jest to nawet wymagane. Z tym protokołem związana jest też kłódeczka, którą możemy zaobserwować przy adresie strony internetowej.

Sam temat szyfrowania jest znacznie szerszy i nie będziemy go dzisiaj omawiać, jednak wspomnę tylko o tym, że w celu udostępnienia szyfrowanej wersji, serwer musi mieć zainstalowany certyfikat. Mamy tutaj trzy rodzaje:

  1. Certyfikat "domowej roboty", wygenerowany samemu. To on zwykle powoduje, że przeglądarka internetowa najpierw nas pyta, czy chcemy wejść na "niebezpieczną stronę".
  2. Certyfikat Let's Encrypt, zarządzany przez organizację udostępniającą darmowe certyfikaty tego typu. Jest to jak najbardziej zaufany dostawca, jednak niektórym może nie wystarczyć, zwłaszcza przy stronach, które muszą wybitnie stawiać na bezpieczeństwo (np. fintech).
  3. Certyfikat od dostawców usług zaufania - to już najwyższy stopień wtajemniczenia, dający nam certyfikaty podpisane przez szanowaną instytucję. Jak się pewnie domyślacie - nie za darmo.

Dla większości stron zdecydowanie wystarczy certyfikat wygenerowany przez narzędzie Let's Encrypt, szczególnie jeśli mamy dostęp do konsoli na serwerze oraz wiemy, czym się różni serwer od domeny.

Czy HTTP to to samo co HTML?

Nie - HTTP to protokół, podczas gdy HTML (Hypertext Markup Language) to język oparty o znaczniki (znane także jako tagi), który służy do opisu strony internetowej. To jest właśnie to, co jest wysyłane jako treść strony internetowej i co interpretuje przeglądarka, aby wyświetlić witrynę w sposób zaprojektowany przez jej autorów. Co ciekawe, każdy z nas może podejrzeć zawartość takiej strony - wystarczy (choćby czytając ten tekst) kliknąć prawym przyciskiem myszy i wybrać opcję "Zbadaj element" lub "Sprawdź element" (w zależności od przeglądarki).

Oczywiście, sprawa nie jest tak prosta - HTML może zawierać wiele informacji, z których nie każda jest przeznaczona do odpowiedniego wyświetlania danych, ale np. dla wyszukiwarek. Dodatkowo, bywają strony ładowane dynamicznie, które dopiero za pomocą skryptów napisanych w JavaScript dokładają w trakcie kolejne elementy witryny. Tym niemniej, wszystko opiera się na poczciwych tagach, ich atrybutach oraz zawartości, którą ze sobą niosą.

Najpopularniejsze typy żądań - GET i POST

Są to dwa typy żądań (czy raczej metody) HTTP, z którymi mamy do czynienia na co dzień, przeglądając Internet. I to każdy z nas - niezależnie od tego, czy jesteśmy programistami, czy zwykłymi użytkownikami, którzy czytają sobie ścianę na Facebooku.

Metoda GET służy zwykle do pobierania danych. Jest to więc najzwyklejsza prośba użytkownika o wyświetlenie strony internetowej - wpisujemy adres WWW, przeglądarka pod spodem wykonuje żądanie GET-owe, a w odpowiedzi dostajemy zapis HTML. Jest to najbardziej podstawowy typ żądania HTTP, który parametry do wyświetlania umieszcza zazwyczaj w samym adresie. Zobaczmy zresztą na przykładzie tego bloga:

https://wildasoftware.pl/blog?categories=feedybacky&page=1

To, co w adresie widzimy po znaku zapytania, to właśnie parametry żądania. Są to dodatkowe informacje do adresu (którym w tym przypadku jest "https://wildasoftware.pl/blog"), pozwalające na zawężenie kryteriów tego, co chce uzyskać użytkownik. Kolejne parametry są oddzielone od siebie ampersandami (&). Taką strukturę wykorzystuje się m.in. do filtrowania danych, co umożliwia potem skopiowanie adresu i użycie go w przyszłości z już ustawionymi warunkami.

GET służy zatem zajczęściej do pobrania danych. Można zatem przewidzieć, że POST pozwala nam przesłać informacje do serwera w celu ich zapisania i w taki sposób rzeczywiście jest najczęściej wykorzystywany. Natomiast musicie pamiętać, że jest to raczej konwencja - gdy ktoś będzie chciał, to GET-em także może zapisywać dane, a POST-em je pobierać. Natomiast powód, dla którego konwencję lepiej utrzymać, jest m.in. bezpieczeństwo. Dlaczego?

POST nie przesyła parametrów w adresie URL, gdzie mogą być np. zapamiętane przez przeglądarkę i podpowiadane na podstawie historii. W tym przypadku argumenty stanowią zawartość żądania, która nie występuje jawnie w adresie, ale jest do niego dołączana "w tle". Nadal można ją bez problemu podejrzeć w przeglądarce, jednak jest to trochę trudniejsze niż w przypadku GET-ów. To też sprawia, że trudniej odzyskać przesłane wartości z historii, a o to chodzi np. w zabezpieczaniu operacji logowania do serwisów.

Tak naprawdę w GET również możemy przesyłać dane w ciele żądania, a w POST - wykorzystywać parametry w URL. Jednak nie bez powodu te typy żądań są rozdzielone. Zawierają też nieco więcej sekretów w sobie (szczególnie POST), jednak aby nie mieszać Wam dodatkowo w głowach, zatrzymamy się w tym miejscu.

Inne metody HTTP

GET i POST nie są jedynymi metodami HTTP, jakie są dostępne. Popularyzacja usług REST-owych przyniosła ze sobą także rozpowszechnienie choćby PUT i DELETE.

Ten pierwszy typ jest podobny do POST-a i też pozwala przesłać dane w ciele żądania, jednak posiada również różnice. W tym jedną dotyczącą konwencji - przyjęło się, że POST służy do wprowadzania danych, a PUT do ich aktualizacji. Lub... odwrotnie - spotykamy bowiem dwie konwencje, które zamieniają nawzajem znaczenie tych dwóch metod i tak naprawdę od zespołu IT zwykle zależy, do czego będą wykorzystywać dany typ żądania.

DELETE z kolei zazwyczaj pełni funkcję, która wynika z samej nazwy - usuwanie danych. Co ciekawe, jest dość blisko "spokrewnione" z GET-em, gdyż również posiada parametry bezpośrednio w URL-u i z tej racji użycie DELETE powinno być ściśle kontrolowane przez aplikację webową pod kątem uprawnień.

To nie koniec metod HTTP - istnieją bowiem jeszcze:

  • HEAD - pobranie samych informacji o zasobie, ale nie jego zawartości. Co ciekawe, może być używane przy atakowaniu strony.
  • OPTIONS - pobranie informacji o dostępności metody i jej wymaganiach. Używane zazwyczaj przy sprawdzaniu tzw. CORS-ów (o których będzie okazja kiedyś opowiedzieć).
  • TRACE - diagnostyka połączenia.
  • CONNECT - żądanie dla tunelowania i serwerów proxy.
  • PATCH - aktualizacja jedynie fragmentu informacji.

Są to jednak metody rzadko wykorzystywane "jawnie", a z powyższych tylko HEAD i OPTIONS są dość często spotykane w aplikacjach webowych. Tym niemniej, warto wiedzieć, że istnieją, gdyż ułatwiają np. analizę komunikacji w przypadku próby wykrywania problemów na stronie lub w połączeniu.

Podsumowanie

Ten artykuł nie miał na celu pełnego omówienia standardu HTTP i jego metod, a jedynie wprowadzenie dla osób, które dopiero chcą rozpocząć świadome poznawanie zagadnień związanych z zasobami Internetu. Mam nadzieję, że po lekturze tego tekstu takie terminy jak GET czy POST nie będą już dla Was czarną magią, a ikona kłódeczki przy HTTPS przestanie mieć znaczenie wyłącznie dekoracyjne.

Pozdrawiam i dziękuję - Jakub Rojek.

We can do quite a bit and what is more, our skills and resources are at your disposal. Take a peek at what we can offer you.

About author

Jakub Rojek

Lead programmer and co-owner of Wilda Software, with many years of experience in software creation and development, but also in writing texts for various blogs. A trained analyst and IT systems architect. At the same time he is a graduate of Poznan University of Technology and occasionally teaches at this university. In his free time, he enjoys playing video games (mainly card games), reading books, watching american football and e-sport, discovering heavier music, and pointing out other people's language mistakes.

Jakub Rojek