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



Podobne dokumenty
Protokół HTTP 1.1 *) Wprowadzenie. Jarek Durak. rfc2616 źródło

Systemy internetowe. Wykład 5 Architektura WWW. West Pomeranian University of Technology, Szczecin; Faculty of Computer Science

Technologie internetowe

Technologie sieciowe Sprawozdanie z labolatorium. Lista 5

XML-RPC: Zdalne wykonywanie procedur


Programowanie Sieciowe 2 Protokoły komunikacyjne: HTTP

Technologie Internetu. Protokół HTTP. Aleksander Denisiuk.

Języki programowania wysokiego poziomu WWW

Protokół HTTP. 1. Protokół HTTP, usługi www, model request-response (żądanie-odpowiedź), przekazywanie argumentów, AJAX.

Zmienne i stałe w PHP

Tworzenie witryn internetowych PHP/Java. (mgr inż. Marek Downar)

Protokół HTTP. Omówienie standardu z analizą ruchu sieciowego

HTTP W 5-CIU PYTANIACH MICHAŁ KOPACZ

CGI (Common Gateway Interface)

Ataki na aplikacje WWW. Łomem, czy wytrychem? Jak dobrać się do aplikacji WWW

76.Struktura oprogramowania rozproszonego.

Aplikacje WWW. Wykład 4. Protokół HTTP. wykład prowadzi: Maciej Zakrzewicz. Protokół HTTP

Programowanie w Internecie

Politechnika Gdańska Wydział Elektrotechniki i Automatyki Kierunek: Automatyka i Robotyka Studia stacjonarne I stopnia: rok I, semestr II

Wykład 3 / Wykład 4. Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak

HTTP, CGI, Perl. HTTP HyperText Transfer Protocol. CGI Common Gateway Interface. Perl Practical Extraction and Report Language

ZESZYTY ETI ZESPOŁU SZKÓŁ W TARNOBRZEGU Nr 2 Seria: Teleinformatyka 2013

Kontrola sesji w PHP HTTP jest protokołem bezstanowym (ang. stateless) nie utrzymuje stanu między dwoma transakcjami. Kontrola sesji służy do

Źródła. cript/1.5/reference/ Ruby on Rails: AJAX: ssays/archives/

TCP/IP. Warstwa aplikacji. mgr inż. Krzysztof Szałajko

Programowanie Aplikacji Sieciowych

Plan wykładu. 1. Protokół FTP. 2. Protokół HTTP, usługi www, model request-response (żądanie-odpowiedź), przekazywanie argumentów, AJAX.

Sprawozdanie Sieci komputerowe i bazy danych Laboratorium nr 4

Aplikacje webowe. mgr inż. Aleksander Smywiński-Pohl. Elektroniczne Przetwarzanie Informacji

Wybrane działy Informatyki Stosowanej

Specyfikacja instalacji usługi SMS Premium w Przelewy24.pl

Laboratorium nr 4 - Badanie protokołów WWW

1. Model klient-serwer

Sprawozdanie nr 4. Ewa Wojtanowska

Programowanie w Sieci Internet Blok 2 - PHP. Kraków, 09 listopada 2012 mgr Piotr Rytko Wydział Matematyki i Informatyki

SIP Studia Podyplomowe Ćwiczenie laboratoryjne Instrukcja

Protokół wymiany sentencji, wersja 1

Problemy z uwierzytelnianiem HTTP

DOKUMENTACJA TECHNICZNA SMS API MT

Sieci komputerowe. Wykład 8: Warstwa zastosowań: FTP i HTTP. Marcin Bieńkowski. Instytut Informatyki Uniwersytet Wrocławski

Hosting WWW Bezpieczeństwo hostingu WWW. Dr Michał Tanaś (

CGI i serwlety. Plan wykładu. Wykład prowadzi Mikołaj Morzy. Przykład: serwlety vs. szablony. Implementacja logiki prezentacji

Sieciowe systemy informacyjne

Specyfikacja techniczna. mprofi Interfejs API

Zadanie programistyczne nr 3 z Sieci komputerowych

Zbieranie podstawowych śladów działalności.

Architektura aplikacji sieciowych. Architektura klient-serwer

Typy przetwarzania. Przetwarzanie zcentralizowane. Przetwarzanie rozproszone

Zaawansowany kurs języka Python

Zadanie1: Odszukaj w serwisie internetowym Wikipedii informacje na temat protokołu http.

Specyfikacja HTTP API. Wersja 1.6

Sieci komputerowe i bazy danych

Płatności CashBill - SOAP

Dokumentacja SMS przez FTP

JĘZYK PYTHON - NARZĘDZIE DLA KAŻDEGO NAUKOWCA. Marcin Lewandowski [ mlew@ippt.gov.pl ]

I.Wojnicki, Tech.Inter.

Aplikacje internetowe - laboratorium

Aplikacje WWW Wprowadzenie

Laboratorium 6.7.2: Śledzenie pakietów ICMP

Instrukcja obsługi serwera FTP v

Programowanie Komponentowe WebAPI

Laboratorium 3.4.2: Zarządzanie serwerem WWW

Języki skryptowe - PHP. PHP i bazy danych. Paweł Kasprowski. pawel@kasprowski.pl. vl07

Specyfikacja interfejsów usług Jednolitego Pliku Kontrolnego

Tworzenie witryn internetowych PHP/Java. (mgr inż. Marek Downar)

FTP co to takiego? FTP File Transfer Protocol (Protokół Przesyłania Plików) RFC 114,959

Gatesms.eu Mobilne Rozwiązania dla biznesu

Przedmiot: Programowanie usług internetowych - Delphi Przygotował: K. Strzałkowski Rok V. Semestr IX. Wydział ZiMK

PLAN WYNIKOWY PROGRAMOWANIE APLIKACJI INTERNETOWYCH. KL IV TI 6 godziny tygodniowo (6x15 tygodni =90 godzin ),

Bezpieczeństwo WWW. Plan prezentacji. WWW a protokoły TCP/IP; URL. Czym jest WWW?

ZABEZPIECZENIE KOMUNIKACJI Z SYSTEMEM E-PŁATNOŚCI

Dokumentacja interfejsu HTTPD. Platforma BSMS.PL Instrukcja podłączenia po przez http

Aukcja trwa od momentu, gdy informacje o przedmiocie są dostępne dla klientów, a kończy się wraz z wysłaniem opisanego dalej komunikatu FINISH_MSG.

Dokumentacja REST API v 3.0. Kraków, 7 marca FreshMail, ul. Fabryczna 20a, Kraków tel , freshmail.

Języki programowania wysokiego poziomu. PHP cz.3. Formularze

Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV

Dokumentacja końcowa projektu z ZPR

POLITYKA PRYWATNOŚCI ORAZ POLITYKA PLIKÓW COOKIES W Sowa finanse

Zygmunt Kubiak Instytut Informatyki Politechnika Poznańska

Wykład 6: PHP: praca z bazą danych MySQL, cz.2

Sprawozdanie Sieci komputerowe i bazy danych Laboratorium nr 4 Wojciech Kaczmarski

Aplikacje WWW - laboratorium

Serwery WWW. Konfiguracja. Zadania serwera. NCSA httpd 1.5

Plan całości wykładu. Warstwa łącza i sieci lokalne

Tomasz Greszata - Koszalin

ZPKSoft WDoradca. 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja

Enkapsulacja RARP DANE TYP PREAMBUŁA SFD ADRES DOCELOWY ADRES ŹRÓDŁOWY TYP SUMA KONTROLNA 2 B 2 B 1 B 1 B 2 B N B N B N B N B Typ: 0x0835 Ramka RARP T

I.Wojnicki, Tech.Inter.

Wybrane działy Informatyki Stosowanej

RPC Remote Procedural Call. Materiały do prezentacji można znaleźć na stronie:

Skąd dostać adres? Metody uzyskiwania adresów IP. Statycznie RARP. Część sieciowa. Część hosta

Hosting WWW Bezpieczeństwo hostingu WWW. Dr Michał Tanaś (

Obsługa incydentów bezpieczeństwa: część I, z punktu widzenia menadżera. OWASP The OWASP Foundation

Programowanie współbieżne i rozproszone

Akademia Górniczo-Hutnicza im. Stanisława Staszica

Spring Web MVC, Spring DI

systemów intra- i internetowych Platformy softwarowe dla rozwoju Architektura Internetu (2) Plan prezentacji: Architektura Internetu (1)

Programowanie w Internecie

Quiz Aplikacja internetowa

Transkrypt:

HTTP + CGI

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

HTTP = Hypertext Transfer Protocol RFC2616 używany do transferu danych dowolnego typu, w szczególności dokumentów HTML typowa sesja komunikacyjna: klient (przeglądarka) nawiązuje połączenie (zwykle na porcie 80) klient wysyła żądanie HTTP (request ) serwer odsyła odpowiedź (response ) serwer zrywa połączenie oznacza to, że HTTP w podstawowej postaci jest protokołem bezstanowym (stateless ) - pomiędzy sesjami nie przechowuje się żadnych danych

struktura żądania i odpowiedzi jest niemal identyczna i używa słów języka angielskiego żądanie i odpowiedź składa się z: linii nagłówkowej (innej dla żądania i odpowiedzi), zakończonej \r\n zero lub więcej linii parametrów (oryg. headers ), zakończonych \r\n (każda) linii pustej (\r\n) opcjonalnego bloku danych o dowolnej strukturze (w tym amorficznego)

przykładowe żądanie: GET /index.html HTTP/1.1 Host: www.example.com CRLF (\r\n)

linia nagłówkowa żądania GET /path/to/resource HTTP/1.0 identyfikator tzw. metody http interesujące dla nas są: GET HEAD POST nazwy metod powinny być pisane wielkimi literami

linia nagłówkowa żądania GET /path/to/resource HTTP/1.0 parametr metody w tym przypadki identyfikator zasobu, który ma być sprowadzony w wyniku wykonania metody GET

linia nagłówkowa żądania GET /path/to/resource HTTP/1.0 identyfikator wersji protokołu HTTP akceptowanej przez klienta (wielkie litery)

linia nagłówkowa odpowiedzi: HTTP/1.0 200 OK identyfikator wersji protokołu HTTP, jaką posługuje się serwer

linia nagłówkowa odpowiedzi: HTTP/1.0 200 OK trzycyfrowy kod statusowy odpowiedzi: 1xx informacja 2xx sukces 3xx przekierowanie klienta do innego zasobu 4xx błąd wywołany zachowaniem klienta 5xx błąd wywołany zachowaniem serwera

linia nagłówkowa odpowiedzi: HTTP/1.0 200 OK opis kodu statusowego zwróconego przez serwer; nie jest opisany przez standard i może zmieniać się w zależności od oprogramowania serwera

Linie parametrów linie parametrów dostarczają dodatkowej informacji odnośnie zgłaszanego żądania lub zwracanej odpowiedzi każda linia parametru kończy się znakami \r\n każda linia zbudowana jest schematu: Param-Name: val nazwy parametrów nie są wrażliwe na rejestr liter znak dwukropka może być otoczony dowolną (w tym zerową) liczbą spacji lub znaków tabulacji linie zaczynające się spacją lub znakiem tabulacji uznawane są za kontynuację linii poprzedniej

Linie parametrów poniższe linie parametrów są równoważne: Param1: PARAM1: value1, value2 value1, value-1b

Linie parametrów norma HTTP/1.0 definiuje 16 parametrów żaden z nich nie jest obowiązkowy norma HTTP/1.1 definiuje 46 parametrów, w tym jeden obowiązkowy: HOST

Blok danych jeśli zapytanie/odpowiedź wymaga przesłania dodatkowych danych, umieszcza się je w bloku danych otwieranym nagłówkiem o poniższej postaci: Content-Type: <typ danych wg kodowania MIME> Content-Length: <długość danych w bajtach> np. Content-Type: image/jpeg Content-Length: 65536

Przykładowa konwersacja (HTTP/1.0): przeglądarka nawiązuje połączenie z serwerem przeglądarka wysyła zapytanie: GET /docs/form.html HTTP/1.0 From: client@server.com User-Agent: MySuperBrowser/1.5 serwer odsyła odpowiedź: HTTP/1.0 200 OK Date: Tue, 06 Dec 2011 23:23:23 GMT Content-Type: text/html Content-Length: 1354 <html><body>...</body></html> serwer zrywa połączenie

Metoda HEAD działa jak GET z tym wyjątkiem, że odsyła do klienta wyłącznie nagłówek odpowiedzi nie wywołuje transferu żadnego zasobu służy do odpytania serwera o metadane ewentualnie sprowadzanej zawartości

Metoda POST służy (zwykle) do wysyłania z przeglądarki do serwera danych, które po stronie serwera będą podlegać aktywnemu przetworzeniu (np. dane formularza) różni się do GET następującymi elementami: zawsze transmituje się blok danych, zwykle poprzedzonych parametrami Content-Type: i Content-Length: URL przesyłany jako parametr metody opisuje nie żądany zasób, a program, który ma przetworzyć żądane dane (uwaga! zachowanie takie można również aktywować metodą GET) należy spodziewać się, że zawartość odesłana przez serwer będzie wygenerowana w locie, a nie wzięta ze statycznego pliku

HTTP 1.1 strona klienta klient używający HTTP 1.1 obowiązany jest użyć w zapytaniu parametru host specyfikującego adres domenowy docelowego hosta (w postaci kanonicznej, bez prefiksu protokołowego) celem tego postępowania jest umożliwienie multihostingu po stronie serwera (rezydowania różnych serwisów WWW pod tym samym adresem IP serwera HTTP) przykładowe zapytanie w stylu HTTP 1.1: GET /path/file.html HTTP/1.1 Host: www.host1.com:80 określenie numeru portu może być pominięte, jeśli używa się numeru domyślnego

HTTP 1.1 strona klienta klient używający HTTP 1.1 musi być przygotowany na to, że serwer może używać przesyłania danych pokawałkowanych (chunk transfers ) odesłanie danych kawałkowanych jest sygnalizowane użyciem parametru Transfer-Encoding: chunked w nagłówku odpowiedzi serwera każdy z kawałków rozpoczyna się linią postaci: size-in-hex; ignore-me gdzie: size-in-hex rozmiar kawałka w bajtach jako liczba szesnastkowa ignore-me nieobjęte standardem wyznania serwera

HTTP 1.1 strona klienta za ostatnim kawałkiem serwer wysyła linię zawierającą wyłącznie znak 0 (zero), po której ewentualnie mogą wystąpić dalsze parametry z nagłówka odpowiedzi pokawałkowanej serwer używa, gdy rozmiar transferowanych danych nie da się przewidzieć z góry

HTTP 1.1 strona klienta odpowiedź pokawałkowana: HTTP/1.1 200 OK Content-Type: text/plain Transfer-Encoding: chunked 1a; oj tam oj tam abcdefghijklmnopqrstuvwxyz 10 1234567890abcdef 0 równoważna odpowiedź niepokawałkowana HTTP/1.1 200 OK Content-Type: text/plain abcdefghijklmnopqrstuvwxyz1234567890abcdef

HTTP 1.1 strona klienta serwer HTTP/1.1 implementuje mechanizm polegający na utrzymywania połączenia z klientem mimo zakończenia transferu odpowiedzi (persistent connections ) jeśli klient nie implementuje tego mechanizmu bądź nie chce go wykorzystywać, musi w nagłówku zapytania wysłać parametr postaci: Connection: close

HTTP 1.1 strona klienta serwer HTTP/1.1 może (w czasie oczekiwania na zakończenie transferu zapytania klienta) odesłać komunikat postaci: HTTP/1.1 100 Continue komunikat ten klient może zignorować

HTTP 1.1 strona serwera serwer implementujący HTTP/1.1 ma obowiązek wymuszać na kliencie przesyłanie parametru Host najczęściej realizuje się to odsyłając klientowi następującą odpowiedź: HTTP/1.1 400 Bad Request Content-Type: text/html Content-Length: 111 <html><body> <h2>no Host: header received</h2> HTTP 1.1 requests must include the Host: header. </body></html>

HTTP 1.1 strona serwera serwer implementujący HTTP/1.1 może (po odebraniu pierwszej linii zapytania od klienta) wysłać mu (opisaną wcześniej) odpowiedź 100 Continue serwer implementujący HTTP/1.1 jest obowiązany opatrywać każdą odpowiedź znacznikiem czasowym postaci: (czasy zawsze wg GMT) Date: Thu, 08 Dec 2011 23:23:23 GMT

HTTP 1.1 strona serwera jeśli klient, korzystając z persistent connection, prześle więcej zapytań niż jedno, serwer powinien odpowiedzieć na wszystkie w dokładnie takiej samej kolejności jeśli serwer napotka zapytanie zawierające parametr Connection: close, powinien zerwać połączenie natychmiast po odesłaniu odpowiedzi na to zapytanie

Wybrane parametry zapytań/odpowiedzi HTTP parametr: zapytanie: odpowiedź: znaczenie: przykład: Accept tak nie typy MIME akceptowane przez klienta Accept: text/plain

Wybrane parametry zapytań/odpowiedzi HTTP parametr: zapytanie: odpowiedź: znaczenie: przykład: Accept-Charset tak nie rodzaje kodowania akceptowane przez klienta Accept-Charset: utf-8

Wybrane parametry zapytań/odpowiedzi HTTP parametr: zapytanie: odpowiedź: znaczenie: przykład: Accept-Encoding tak nie rodzaje kompresji danych akceptowane przez klienta Accept-Encoding: gzip

Wybrane parametry zapytań/odpowiedzi HTTP parametr: zapytanie: odpowiedź: znaczenie: przykład: Accept-Language tak nie języki preferowane przez klienta Accept-Language: pl-pl, en-us

Wybrane parametry zapytań/odpowiedzi HTTP parametr: zapytanie: odpowiedź: znaczenie: przykład: Connection tak tak odrzucenie/zakończenie persistent connection Connection: close

Wybrane parametry zapytań/odpowiedzi HTTP parametr: zapytanie: odpowiedź: znaczenie: przykład: Content-Disposition nie tak zasugerowanie przeglądarce, aby otworzyła okno dialogowe Zapisz jako... Content-Disposition: attachment; filename=virus.exe

Wybrane parametry zapytań/odpowiedzi HTTP parametr: zapytanie: odpowiedź: znaczenie: przykład: Content-Encoding nie tak rodzaj kompresji danych wykonany na danych dołączonych Content-Encoding: gzip

Wybrane parametry zapytań/odpowiedzi HTTP parametr: zapytanie: odpowiedź: znaczenie: przykład: Content-Language nie tak język dokumentu dołączonego Content-Language: pl-pl

Wybrane parametry zapytań/odpowiedzi HTTP parametr: zapytanie: odpowiedź: znaczenie: Content-Length tak tak długość dołączonych danych w bajtach przykład: Content-Length: 348

Wybrane parametry zapytań/odpowiedzi HTTP parametr: zapytanie: odpowiedź: znaczenie: przykład: Content-Type tak tak type MIME dołączonych danych Content-Type:application/vnd.oasis.opendocument.text

Wybrane parametry zapytań/odpowiedzi HTTP parametr: zapytanie: odpowiedź: znaczenie: przykład: From tak nie adres e-mail użytkownika w imieniu którego występuje klient From: user@server.com

Wybrane parametry zapytań/odpowiedzi HTTP parametr: zapytanie: odpowiedź: znaczenie: przykład: Host tak nie adres domenowy serwera Host: www.wi.zut.edu.pl

Wybrane parametry zapytań/odpowiedzi HTTP parametr: Referer * zapytanie: odpowiedź: znaczenie: przykład: tak nie adres strony, z której nastąpiło dolinkowanie do żądanego zasobu Referer: http://detox.wi.zut.edu.pl/sw/index.html * W nazwie tego parametru zawarty jest błąd ortograficzny poprawna pisownia to referrer

Wybrane parametry zapytań/odpowiedzi HTTP parametr: zapytanie: odpowiedź: znaczenie: przykład: Server nie tak ciąg znaków identyfikujący oprogramowania serwera Server: Apache/1.3.27 (Unix) (Debian/Linux)

Wybrane parametry zapytań/odpowiedzi HTTP parametr: zapytanie: odpowiedź: znaczenie: przykład: Transfer-encoding nie tak sposób przesyłania danych dołączonych (zdefiniowane standardem są: chunked, compress, deflate, gzip Transfer-Encoding: chunked

Wybrane parametry zapytań/odpowiedzi HTTP parametr: zapytanie: odpowiedź: znaczenie: przykład: User-agent tak nie ciąg znaków identyfikujących oprogramowanie klienta Mozilla/5.0 (X11; Linux i686; rv:6.0) Gecko/20100101 Firefox/6.0

CGI literatura: http://www.w3.org/cgi/ http://tools.ietf.org/html/rfc3875

CGI = Common Gateway Interface znormalizowany interfejs komunikacji pomiędzy oprogramowaniem serwera HTTP a dowolnymi innymi programami uruchamianymi na żądanie serwera de facto niezmienny od od 1995, powszechnie implementowany, chociaż coraz rzadziej używany wprost, a częściej chowany za interfejsami na wyższym poziomie abstrakcji niezależna od platformy sprzętowej/systemowej, opierający się na maksymalnie uproszczonych, dostępnych w każdym systemie, konwencji komunikacyjnych

większość (wszystkie?) serwerów HTTP ma zaimplementowany mechanizm CGI (niekiedy uproszczony bądź zmodyfikowany) programy CGI można pisać w dowolnym języku programowania (najczęściej z wielu powodów jest to Perl, coraz powszechniej wypierany przez python i ruby wiele języków ogólnego przeznaczenia ma własne biblioteki wspomagające obsługę CGI koncepcja interfejscu CGI narzuca tworzenie nowego procesu na każde żądanie serwera; może to powodować to duży narzut obciążenia serwera (środek zaradczy FastCGI)

Przykładowy dialog przeglądarki z serwerem WWW 1. serwer przesyła dokument HTML opisujący formularz przeglądarka Serwer WWW

Przykładowy dialog przeglądarki z serwerem WWW 2. użytkownik wypełnia formularz i inicjuje jego odesłanie; przeglądarka przesyła zakodowany formularz do serwera przeglądarka Serwer WWW

Przykładowy dialog przeglądarki z serwerem WWW 3. serwer WWW uruchamia wskazany program tzw. skrypt CGI i przekazuje mu zakodowane dane formularza. Serwer WWW Skrypt CGI

Przykładowy dialog przeglądarki z serwerem WWW 4. skrypt CGI przetwarza formularz i wykonuje wszelkie inne niezbędne czynności, po czym generuje dokument HTML i odsyła go serwerowi WWW Serwer WWW Skrypt CGI

Przykładowy dialog przeglądarki z serwerem WWW 5. serwer przesyła do przeglądarki dokument HTML wygenerowany przez skrypt, itd., itd., itd... przeglądarka Serwer WWW

Skrypty CGI: lokowane zwyczajowo w katalogu /cgi-bin/ skrypt CGI musi być wykonywalny z punktu widzenia systemu operacyjnego język programowania dowolny (od skryptów shellowych po Objective Caml) skrypt CGI odczytuje przesłane mu dane z: stdin (przy metodzie POST) zmiennej środowiskowej (przy metodzie GET) skrypt CGI odsyła wygenerowną odpowiedź wypisując ją na stdout

Formularz w HTML <FORM ACTION="skrypt" METHOD="metoda"> : pola formularza : </FORM> gdzie: skrypt: http://serwer.domena/cgi-bin/skrypt metoda: GET lub POST

Kodowanie danych formularza pole1=wartość&pole2=wartość&... spacja = + + = %2B znaki spoza ASCII = %xx jest to tzw. URL-encoding, opisany szczegółowo w RFC1738 (http://tools.ietf.org/html/rfc1738)

Zmienne środowiskowe znane skryptowi CGI: zmienna: CONTENT_LENGTH metoda: POST znaczenie: liczba bajtów danych zakodowanego formularza, jakie można odczytać z STDIN

Zmienne środowiskowe znane skryptowi CGI: zmienna: CONTENT_TYPE metoda: POST znaczenie: typ danych wysłanych z przeglądarki (wg. standardu MIME)

Zmienne środowiskowe znane skryptowi CGI: zmienna: QUERY_STRING metoda: POST (zawsze pusta) GET znaczenie: zakodowana zawartość formularza odebrana z przeglądarki (GET)

Zmienne środowiskowe znane skryptowi CGI: zmienna: HTTP_ACCEPT metoda: POST GET znaczenie: typy danych (MIME) akceptowanych przez przeglądarkę; najczęściej */*

Zmienne środowiskowe znane skryptowi CGI: zmienna: HTTP_USER_AGENT metoda: POST GET znaczenie: nazwa przeglądarki (klienta HTTP) w formacie: nazwa/wersja/rewizja

Zmienne środowiskowe znane skryptowi CGI: zmienna: GATEWAY_INTERFACE metoda: POST GET znaczenie: wersja CGI obsługiwana przez serwer HTTP np. CGI/1.1

Zmienne środowiskowe znane skryptowi CGI: zmienna: SCRIPT_NAME metoda: POST GET znaczenie: nazwa uruchomionego skryptu np. /cgi-bin/skrypt

Zmienne środowiskowe znane skryptowi CGI: zmienna: REMOTE_ADDR metoda: POST GET znaczenie: adres IP klienta HTTP

Zmienne środowiskowe znane skryptowi CGI: zmienna: REMOTE_HOST metoda: POST GET znaczenie: nazwa komputera klienta HTTP

Zmienne środowiskowe znane skryptowi CGI: zmienna: REMOTE_USER metoda: POST GET znaczenie: nazwa użytkownika przeglądarki

Zmienne środowiskowe znane skryptowi CGI: zmienna: REQUEST_METHOD metoda: POST GET znaczenie: nazwa metody wywołania skryptu (GET lub POST)

Zmienne środowiskowe znane skryptowi CGI: zmienna: SERVER_NAME metoda: POST GET znaczenie: nazwa serwera, na którym pracuje skrypt

Zmienne środowiskowe znane skryptowi CGI: zmienna: SERVER_SOFTWARE metoda: POST GET znaczenie: nazwa oprogramowania serwera HTTP, który uruchomił skrypt

Zmienne środowiskowe znane skryptowi CGI: zmienna: SERVER_PROTOCOL metoda: POST GET znaczenie: wersja protokołu HTTP obsługiwanego przez serwer HTTP np. HTTP/1.1

Zmienne środowiskowe znane skryptowi CGI: zmienna: SERVER_PORT metoda: POST GET znaczenie: numer portu, na którym nasłuchuje serwer HTTP

Zmienne środowiskowe znane skryptowi CGI: zmienna: PATH_INFO metoda: POST GET znaczenie: wszystko, co w URLu skryptu znajduje się za nazwą skryptu np: URL: server.dom/cgi-bin/skrypt/1/2/3/4 PATH_INFO: /1/2/3/4

Zmienne środowiskowe znane skryptowi CGI: zmienna: PATH_TRANSLATED metoda: POST GET znaczenie: wszystko, co w URLu skryptu znajduje się za nazwą skryptu ale odniesione do katalogu document-root np: URL: server.dom/cgi-bin/skrypt/1/2/3/4 PATH_INFO: /var/www/1/2/3/4