Domena Internetowa Słupsk - Tanio i Profesjonalnie

- | - Domena - DNS - DDNS DNSSEC - Lista domen najwyższego poziomu - Domeny poziomy - Strona internetowa - IP Adres Protokół internetowy - Internet Intranet Ekstranet - Sieci komputerowe - Dostawca usług internetowych - Poczta E-mail - | -
- | - Subdomena - Sklep Internetowy - Serwer - Drzewo - Mnemonik - HTTP HTTPS S-HTTP - Model TCP/IP - DHCP - ARPANET ALOHAnet SIPRNet - BITNET - IETF - Zatruwanie DNS - ISOC - Historia Internetu - Netykieta - | -

Słupsk / Domeny On-line / Hypertext Transfer Protocol Hypertext Transfer Protocol Secure Secure HTTP

HTTP (ang. Hypertext Transfer Protocol) – protokół stworzony przez Tima Bernersa-Lee na potrzeby komunikacji między klientem a serwer w sieci WWW (ang. World Wide Web).

Najnowszą specyfikację HTTP stanowi dokument RFC 2616 ↓. Przy pomocy protokołu klienty HTTP komunikują się z serwerami zamawiając pliki składające się na strony internetowe oraz dostarczają niezbędne do tego informacje, np. treści wprowadzane w formularzach.
Określa on formę żądań klienta (tj. np. przeglądarki www) dotyczących danych oraz formę odpowiedzi serwera na te żądania. W oryginalnych implementacjach był protokołem bezstanowym (ang. stateless), bowiem nie zachowywał żadnych informacji o poprzednich transakcjach z klientem. Pozwalało to znacznie zmniejszyć obciążenie serwera, jednak jest kłopotliwe w sytuacji, gdy np. trzeba zapamiętać konkretny stan dla użytkownika, który wcześniej łączył się już z serwerem. Jeszcze w latach 90. XX wieku firma Netscape wprowadziła początkowo nieformalne a następnie ustandaryzowane rozszerzenie znane jako ciasteczka. Inne podejścia to m.in. sesje po stronie serwera, ukryte parametry – gdy aktualna strona zawiera formularz – oraz parametry umieszczone w URL-u (jak np. /index.php?userid=3).
Serwery obsługujące HTTP standardowo nasłuchują na porcie TCP numer 80.

Metody HTTP
1. GET – pobranie zasobu wskazanego przez URI, może mieć postać warunkową jeśli w nagłówku występują pola warunkowe takie jak "If-Modified-Since"
2. HEAD – pobiera informacje o zasobie, stosowane do sprawdzania dostępności zasobu
3. PUT – przyjęcie danych przesyłanych od klienta do serwera, najczęściej aby zaktualizować wartość encji
4. POST – przyjęcie danych przesyłanych od klienta do serwera (np. wysyłanie zawartości formularzy)
5. DELETE – żądanie usunięcia zasobu, włączone dla uprawnionych użytkowników
6. OPTIONS – informacje o opcjach i wymaganiach istniejących w kanale komunikacyjnym
7. TRACE – diagnostyka, analiza kanału komunikacyjnego
8. CONNECT – żądanie przeznaczone dla serwerów pośredniczących pełniących funkcje tunelowania
9. PATCH – aktualizacja części danych
Metoda CONNECT nie jest częścią standardu HTTP/1.1, jednak jest powszechnie implementowana na podstawie dokumentu internet-draft wygasłego w 1999 roku.

Typowe zapytanie HTTP
1. GET / HTTP/1.1 (prośba o zwrócenie dokumentu o URI / zgodnie z protokołem HTTP 1.1)
2. Host: example.com (wymagany w HTTP 1.1 nagłówek Host służący do rozpoznania hosta, jeśli serwer na jednym IP obsługuje kilka VirtualHostów)
3. User-Agent: Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 (nazwa aplikacji klienckiej)
4. Accept: text/xml,application/xml, application/xhtml+xml, text/html;q=0.9,text/plain;q=0.8 (akceptowane (bądź nieakceptowane dla q=0) przez klienta typy plików)
5. Accept-Language: pl,en-us;q=0.7,en;q=0.3 (preferowany język strony – nagłówek przydatny przy Language negotiation)
6. Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.7 (preferowane kodowanie znaków, patrz strona kodowa)
7. Keep-Alive: 300 (czas, jaki klient chce zarezerwować do następnego zapytania w przypadku połączenia Keep-Alive)
8. Connection: keep-alive (chęć nawiązania połączenia stałego Keep-Alive z serwerem HTTP/1.0)
9. znak powrotu karetki i nowej linii (CRLF)
HTTP/1.1 dopuszcza wysłanie kilku żądań naraz (pipelining). HTTP/1.0 zakłada jedno żądanie i jedną odpowiedź.

Odpowiedź serwera WWW
1. HTTP/1.1 200 OK (kod odpowiedzi HTTP - zaakceptowanie i zwrócenie zawartości)
2. Date: Thu, 20 Dec 2001 12:04:30 GMT (czas serwera)
3. Server: Apache/2.0.50 (Unix) DAV/2 (opis aplikacji serwera)
4. Set-Cookie: PSID=d6dd02e9957fb162d2385ca6f2829a73; path=/ (nakazanie klientowi zapisania ciasteczka)
5. Expires: Thu, 19 Nov 1981 08:52:00 GMT (czas wygaśnięcia zawartości zwróconego dokumentu. Data w przeszłości zabrania umieszczenie dokumentu w pamięci podręcznej. Jest to stara metoda zastąpiona przez Cache-Control)
6. Cache-Control: no-store, no-cache, must-revalidate (no-store zabrania przechowywania dokumentu na dysku, nawet gdy nie jest to pamięć podręczna. must-revalidate nakazuje bezwzględnie stosować się do wytycznych i sprawdzić świeżość dokumentu za każdym razem)
7. Keep-Alive: timeout=15, max=100
8. Connection: Keep-Alive (akceptacja połączenia Keep-Alive dla klientów HTTP/1.0)
9. Transfer-Encoding: chunked (typ kodowania zawartości stosowanej przez serwer)
10. Content-Type: application/xhtml+xml; charset=utf-8 (typ MIME i strona kodowa zwróconego dokumentu)
11. znak powrotu karetki i nowej linii (CRLF)
12. tutaj zawartość dokumentu
HTTP do obsługi połączeń Keep-Alive wymaga, aby odpowiedź od serwera miała znaną długość (przez podanie Content-Length lub użycie Transfer-Encoding: chunked). W przeciwnym wypadku koniec odpowiedzi sygnalizuje zerwanie połączenia i Keep-Alive nie może działać.
Nagłówek Keep-Alive jest rozszerzeniem HTTP/1.0. W HTTP/1.1 ten nagłówek nie jest potrzebny, gdyż połączenia Keep-Alive są domyślne (zachowanie zmienia Connection: close).

HTTPS (ang. Hypertext Transfer Protocol Secure) – protokół HTTP chroniony przy pomocy szyfrowania protokołu TLS (dawniej SSL) i ustandaryzowany w dokumencie RFC 2818 pod rzadziej używaną nazwą HTTP Over TLS.

Szyfrowanie komunikacji ma zapobiegać jej przechwytywaniu między klientem i serwerem czy wręcz modyfikacji przesyłanych danych, zanim dotrą do celu.
W przeciwieństwie do niezabezpieczonego HTTP, którego serwery nasłuchują na porcie 80, serwery obsługujące HTTPS nasłuchują domyślnie na porcie 443 protokołu TCP. Adresy URL zaczynają się od https://, podczas gdy adresy niezabezpieczonego HTTP od http://.

Ograniczenia i rozpowszechnienie
Protokół HTTP realizuje się warstwę wyżej od standardu TLS, który znajduje się na warstwie prezentacji. Najpierw następuje więc wymiana kluczy TLS, a dopiero później możliwe jest przesłanie żądania HTTP. Historycznie uniemożliwiało to serwerom obsługiwanie wielu domen (bądź poddomen) z różnymi certyfikatami przy użyciu jednego adresu IP. Było to spowodowane brakiem informacji o tym, którego certyfikatu X.509 i klucza prywatnego należy użyć do odszyfrowania danych, ponieważ nagłówek HTTP Host jest przekazywany wewnątrz zaszyfrowanej części zapytania (którego z kolei nie można odszyfrować, nie znając domeny). Jedynym obejściem było użycie wspólnego certyfikatu dla wszystkich domen. Problem został zażegnany poprzez wprowadzenie do TLS rozszerzenia SNI (ang. Server Name Indication), które przechowuje informację o domenie w nieszyfrowanej postaci.

Procent domen w Internecie serwujących strony domyślnie po HTTPS na przestrzeni lat:

Domeny Internetowe Słupsk

W3Tech, marzec 2023
W starszych wersjach HTTP szyfrowanie połączenia było rozszerzeniem protokołu. Począwszy od HTTP/2 mimo braku takiego wymogu w RFC, szyfrowanie stało się de facto wymogiem protokołu ze względu na stan implementacji w najpopularniejszych silnikach przeglądarek internetowych.

S-HTTP (Secure HTTP) jest zdefiniowanym w RFC 2660 ↓ rozszerzeniem protokołu HTTP umożliwiającym bezpieczną wymianę informacji między klientem i serwerem z wykorzystaniem szyfrowania.

Został opracowany niemal równolegle z protokołem HTTPS, i w odróżnieniu od tego drugiego, nigdy nie spotkał się z szerszą akceptacją dostawców przeglądarek i serwerów WWW. Ze względu na to nie jest dziś powszechnie spotykany.

- | - NASK - LABORATORIA BIOMETRII NASK - SAFER INTERNET - CERT POLSKA - TASK - ICM - SCI.PL - CHEM.PL - CYFRONET AGH - ISOC POLSKA - KRAJOWY REJESTR DOMEN - | -
- | - ICANN - IANA - INTERNET SOCIETY - WEBBY AWARD - WHO IS - VIRUS TOTAL - | -