HTTP. Photo courtesy: http://www.flickr.com/people/dotbenjamin/. Hypertext Transfer Protocol. Background. HTTP is the protocol used by most web applications Consists of two primary phases REQUEST: a client asks a server for information RESPONSE: the server responds to the clients request
Photo courtesy: http://www.flickr.com/people/dotbenjamin/ Hypertext Transfer Protocol
Background HTTP is the protocol used by most web applications Consists of two primary phases REQUEST: a client asks a server for information RESPONSE: the server responds to the clients request Communication is mostly textual
Request Phase <METHOD> <URL> <VERSION> <NL> <HEADER>:<SP><Value><NL> … <HEADER>:<SP><Value><NL> <NL> BODY OF THE REQUEST An HTTP Request is a "text message": REQUEST LINE: three parts separated by a space: <METHOD>: GET|HEAD|POST|PUT|DELETE <URL>: the document being requested <VERSION>: HTTP version of the client: typically HTTP/1.0. HEADER: Optional lines allowing additional information about the request and/or the client (i.e. browser, operating system, etc.). Each line is a name-value pair. BODY: Optional lines which must be separated from the header by an empty line Entire specification: http://www.ietf.org/rfc/rfc1945.txt
<METHOD> <URL> <VERSION> <NL> <HEADER>:<SP><Value><NL> … <HEADER>:<SP><Value><NL> <NL> BODY OF THE REQUEST Request line:Method Usually either GET or POST POST: The corresponding URL typically denotes a program to execute rather than a document to retrieve Generally used to submit HTML FORMS The message body contains that data to send to the server
<METHOD> <URL> <VERSION> <NL> <HEADER>:<SP><Value><NL> … <HEADER>:<SP><Value><NL> <NL> BODY OF THE REQUEST URL Syntax resource_type://username:password@domain:port/path?query_string#anchor Resource type (aka scheme): Defines the namespace, purpose, and the syntax of the remaining part of the URL. Case insensitive Examples: HTTP: A browser will send an HTTP request to example.org using port 80. MAILTO: A browser will usually start an email system with the username and domain in the "to" field. mailto:bob@example.com Others: HTTPS, GOPHER, FTP Domain: The IP address or textual equivalent (as entered into DNS) Case insensitive Example: The domain google.com or IP address 74.125.255.18 The domain charity.cs.uwlax.edu or IP address 138.49.38.235
URL Syntax resource_type://username:password@domain:port/path?query_string#anchor Port (optional): if omitted, the default port for the specified scheme is used. Well-known ports: 21: File Transfer Protocol (FTP) 22: Secure Shell (SSH) 25: Simple Mail Transfer Protocol (SMTP) 80: Hypertext Transfer Protocol (HTTP) used in the World Wide Web 110: Post Office Protocol (POP) 443: HTTP Secure (HTTPS) Example: http://myvncserver.no-ip.org:5800 will connect to port 5800 of myvncserver.no-ip.org; this port is used by the VNC remote control program and would set up a remote control session. Path: The location of the resource. Case-sensitive(though it may be treated as case-insensitive by some servers). Query string: Information that is passed to the web app Format: n1=v1&n2=v2&… Example: first_name=John&last_name=Doe. Anchor: Specifies a location on the page. Example: http://en.wikipedia.org/wiki/URL#Syntax addresses the beginning of the Syntax section.
URL Examples resource_type://username:password@domain:port/path?query_string#anchor http://courage.cs.uwlax.edu:8080/ port: 8080 which is the tomcat default ftp://apache.cs.utah.edu/apache.org resource_type: ftp http://charity.cs.uwlax.edu/cs120/#grades anchor: grades http://en.wikipedia.org/wiki/Www#Web_Servers anchor: Web_Servers
<METHOD> <URL> <VERSION> <NL> <HEADER>:<SP><Value><NL> … <HEADER>:<SP><Value><NL> <NL> BODY OF THE REQUEST Request Phase:Headers
<METHOD> <URL> <VERSION> <NL> <HEADER>:<SP><Value><NL> . . . <HEADER>:<SP><Value><NL> <NL> BODY OF THE REQUEST Request Examples GET /index.html HTTP/1.1 Host: charity.cs.uwlax.edu GET www.foobar.edu/index.html HTTP/1.0 Accept: text/html If-Modified-Since: Saturday, 15-January-2000 14:37:11 GMT User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) POST /path/script.cgi HTTP/1.0 From: kenny@hunt.com User-Agent: HTTPTool/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 38 user=Kenny&creditCard=1234567890123456
Response Phase <VERSION> <STATUS_CODE> <DESCRIPTION> <NL> <HEADER>:<SP><Value><NL> Content-type: text/html <HEADER>:<SP><Value><NL> <NL> BODY OF THE REQUEST An HTTP Response is a collection of textual lines: STATUS LINE: Made up of three elements which must be separated by a space: VERSION – Identical to request version STATUS CODE – three digit code DESCRIPTION – textual description of the code HEADER: Optional lines allowing additional information about the request. Each line is a name-value pair. The content-type header is required. BODY: Optional lines which must be separated from the header by an empty line Entire specification: http://www.ietf.org/rfc/rfc1945.txt
Response Phase:Status <VERSION> <STATUS_CODE> <DESCRIPTION> <NL> <HEADER>:<SP><Value><NL> … <HEADER>:<SP><Value><NL> <NL> BODY OF THE REQUEST Status Code A three digit code First digit denotes the category 1: Informational 2: Success 3: Redirection 4: Client error 5: Server error
Response Phase : Status Codes
Content-Type The content-type indicates what kind of document is being delivered. text/html image/png application/msword audio/x-mpeg The server is responsible for generating this header
Response example HTTP/1.1 200 OK Date: Tues, 18 May 2004 16:45:13 GMT Server: Apache (Red-Hat/Linux) Last-modified: Tues, 18 May 2004 16:38:38 GMT Etag: "841fb-4b-3d1a0179" Accept-ranges: bytes Content-length: 364 Connection: close Content-type: text/html, charset=ISO-8859-1 12345678901234567890… Check out http://web-sniffer.net/ to see request/response details
HTTP Security Obviously – insecure Aspects of security Privacy – Nobody should be able to obtain my credit card number when sent from client to server Integrity – Nobody should be able to modify my credit card number when sent from client to server Authentication – The clients identity should be correct Nonrepudiation – Neither client nor server should be able to deny receipt of message or sending of message Encryption solves the first two issues – encrypted messages are private (can’t be understood without the key) and insures integrity (can’t modify the message without the key)