1 / 31

HyperText Transfer Protocol {week 13 }

Rensselaer Polytechnic Institute CSC-432 – Operating Systems David Goldschmidt, Ph.D. HyperText Transfer Protocol {week 13 }. Protocols. A protocol is an agreed-upon convention that defines how communication occurs between two (or more?) endpoints

ling
Download Presentation

HyperText Transfer Protocol {week 13 }

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Rensselaer Polytechnic Institute CSC-432 – Operating Systems David Goldschmidt, Ph.D. HyperText Transfer Protocol{week 13}

  2. Protocols • A protocol is an agreed-upon convention that defines how communication occurs between two (or more?) endpoints • All endpoints must “understand” andcorrectly implement the protocol • Protocols must be formally defined, unambiguous, and well-documented • Protocols should address error conditionsand unexpected scenarios

  3. HTTP • HTTP is the protocol for communication between browser apps and Web servers • Web servers are essentially HTTP servers • Protocols have versions • Most clients and servers support version 1.1 • But 1.0 is also in use (maybe also 0.9?!) why?

  4. P Internet messages • Each layer prepends or appends its information in a header or trailer HTTP Request TCP Hdr | HTTP Request IP Hdr | TCP Hdr | HTTP Request Ethernet Hdr | IP Hdr | TCP Hdr | HTTP Request | Cksum

  5. Q P Interprocess communication

  6. A few relevant RFCs • RFC 1945 is the HTTP 1.0 standard • see http://www.ietf.org/rfc/rfc1945.txt • RFC 2616 is the HTTP 1.1 standard • see http://www.ietf.org/rfc/rfc2616.txt • RFC 2396 is the URI standard • see http://www.ietf.org/rfc/rfc2396.txt

  7. What is HTTP? (i) • From the RFC: • HTTP is an application-levelprotocol with the lightnessand speed necessary fordistributed, hypermediainformation systems

  8. What is HTTP? (ii) • Again from the RFC: • HTTP communication generally takes placeover TCP/IP connections • The default port is TCP 80,but other ports can be used • HTTP is not dependent ona specific transport layer https is typically TCP port 443

  9. Connection-oriented • HTTP defines a very simple structure: • A client sends a request • The server sends a response • HTTP supports multiple request/response exchanges over a single connection • e.g. try using telnet to access a Web server....

  10. HTTP 1.0/1.1 request structure (i) • HTTP requests are line-based ASCII text • Lines must alwaysend with "\r\n"(a.k.a. CRLF) • Headers are optional • A blank line separatesthe request from thecontent Request-Line Header(s) ... ... -- blank line -- Content ... ... ... what content?!

  11. HTTP 1.0/1.1 request structure (ii) • The Request-Line consists of 3 tokens: • Each token is separated by a space character • Though "\r\n" is required by the protocol, "\n" seems to work in practice • The HTTP-Version is either HTTP/1.0or HTTP/1.1 Method URI HTTP-Version\r\n

  12. HTTP request methods (i) Method URI HTTP-Version\r\n • The HTTP request’s Method can be: • GET – request information identified bythe given URI (absolute or relative?) • HEAD – request metadata regardingthe given URI (search engines!) • POST – send (i.e. post) informationto the given URI (e.g. via a form)

  13. HTTP request methods (ii) Method URI HTTP-Version\r\n • The HTTP request’s Method can be: • PUT – store information in the locationidentified by the given URI • DELETE – remove the entity identifiedby the given URI (really?)

  14. HTTP request methods (iii) Method URI HTTP-Version\r\n • The HTTP request’s Method can be: • TRACE – used to trace HTTP forwardingthrough proxies, tunnels, etc. • OPTIONS – determines the capabilities ofthe Web server or the characteristics of the named resource

  15. HTTP request methods (iv) Method URI HTTP-Version\r\n • The GET, HEAD, and POST methods are supported everywhere • HTTP 1.1 servers often supportPUT, DELETE, TRACE, andOPTIONS (but not always!) why won’t this work?!

  16. Universal Resource Identifier • The URI is defined in RFC 2396 • An absolute URI consists of four parts: • A relative URI omits the scheme and server: • The server is assumed(since we’re already connected) scheme://hostname[:port]/path /path which one should we use in our HTTP Request-Line?

  17. URIs in practice • In general, relative URIs are used inthe HTTP Request-Line • HTTP 1.1 servers are required to supportabsolute URIs, but not all do • When using a proxy HTTP server, an absolute URI is required • Or else, the proxy server won’t know whereto find the resource (i.e. document)

  18. Request headers (i) • After the Request-Line, the request might have header lines • Header lines specifyattribute name/valuepairs (e.g. User-Agent:) • Note that HTTP 1.1requires the Host:header always beincluded Request-Line Header(s) ... ... -- blank line -- Content ... ... ...

  19. Request headers (ii) • Request headers provide information to the server about the client • Who is making the request • What kind of client is making the request • What kind of content will be accepted • In HTTP 1.0, all headers are optional • In HTTP 1.1, the Host: header must be sent

  20. Example request headers (i) • Headers can be included in any order: • For GET and HEAD requests, that’s the end(though don’t forget the blank line!) GET /index.html HTTP/1.1 Accept: text/html Host: www.rpi.edu From: goldschmidt@gmail.com User-Agent: Mozilla/4.0 Referer: http://somewhere.else.com/rpi.html -- blank line --

  21. Example request headers (ii) • If a POST request is made, the headers must include Content-Length: POST /~goldsd/changegrade.php HTTP/1.1 Accept: */* Host: www.cs.rpi.edu User-Agent: SecretAgent v3.0 Referer: http://somewhere.devious.com/x.php Content-Length: 36 -- blank line -- rin=660123456&item=midterm&grade=104

  22. HTTP response structure (i) • HTTP responses are line-based ASCII text • A Status-Line isalways returned • A blank line separatesthe response from thecontent • Content is a sequenceof bytes (e.g. HTML,image, text, etc.) Status-Line Header(s) ... ... -- blank line -- Content ... ... ...

  23. HTTP response structure (ii) • The Status-Line consists of 3 tokens: • The HTTP-Version is either HTTP/1.0or HTTP/1.1 (and does not necessarily match the corresponding request) • Response status is represented using a 3-digit Status-Code and a human-readable Message HTTP-Version Status-Code Message

  24. HTTP status codes • Status codes are grouped as follows: • 1xx – Informational • 2xx – Success • 3xx – Redirection • 4xx – Client Error • 5xx – Server Error (click me)

  25. Example status lines • Example status lines include: • HTTP/1.0 200 OK • HTTP/1.0 301 Moved Permanently • HTTP/1.0 400 Bad Request • HTTP/1.0 403 Forbidden • HTTP/1.0 500 Internal Server Error

  26. Response headers (i) • After the Status-Line, the response typically has header lines • Header lines specifyattribute name/valuepairs (e.g. Date:) • As with request headers,response headers endwith a blank line Status-Line Header(s) ... ... -- blank line -- Content ... ... ...

  27. Response headers (ii) • Response headers provide information to the client about the entity (i.e. document) • What kind of entity/document • How many bytes are in the document • How the document is encoded • When the document was last modified • The Content-Type header is required, as is the Content-Length header (usually)

  28. Example response headers • Headers can be included in any order: HTTP/1.1 200 OK Date: Wed, 30 Jan 2002 12:48:17 EST Server: Apache/1.17 Content-Type: text/html Content-Length: 1756 Content-Encoding: gzip -- blank line -- 2309fjfjef0jefe0fje2f0je2f0je2f0e2jfe0fje20fj2e0fjef0jef0e2jf0efje0fje02fje20fje2f0ejf0jef2e09fj209g209fj20gag09ha0gh0agha0gjg0jg

  29. Request/response cycle • For HTTP 1.0, default behavior is as follows: • Client sends a complete HTTP request • Server sends back a complete HTTP response • Server closes its socket • Therefore: • If the client needs another document(e.g. images, CSS, etc.), the client mustopen a new socket connection!

  30. HTTP 1.0 persistent connections • In HTTP 1.0, support for persistent connections is available • Multiple requests can be handled over a single TCP/IP socket connection • The Keep-Alive: header is used to keep the connection alive

  31. HTTP 1.1 persistent connections • As of HTTP 1.1, support for persistent connections is available (and is the default) • Multiple requests can be handled over a single TCP/IP socket connection • The Connection: header is used to exchange information about persistence • e.g. Connection:close

More Related