Upload
ling
View
27
Download
3
Tags:
Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
HyperText Transfer Protocol{week 13}
Rensselaer Polytechnic InstituteCSC-432 – Operating SystemsDavid Goldschmidt, Ph.D.
Protocols
A protocol is an agreed-upon convention that defines how communication occurs between two (or more?) endpoints All endpoints must “understand” and
correctly implement the protocol Protocols must be formally defined,
unambiguous, and well-documented Protocols should address error conditions
and unexpected scenarios
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?
Internet messages
Each layer prepends or appends its information in a header or trailer
P
Ethernet Hdr | IP Hdr | TCP Hdr | HTTP Request | Cksum
IP Hdr | TCP Hdr | HTTP Request
TCP Hdr | HTTP Request
HTTP Request
Interprocess communication
P
Q
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
What is HTTP? (i)
From the RFC: HTTP is an application-level
protocol with the lightnessand speed necessary fordistributed, hypermediainformation systems
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
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....
HTTP 1.0/1.1 request structure (i)
HTTP requests are line-based ASCII text Lines must always
end with "\r\n" (a.k.a. CRLF)
Headers are optional A blank line separates
the request from thecontent
Request-Line
Header(s)......
-- blank line --
Content.........
what content?!
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.0 or HTTP/1.1
Method URI HTTP-Version\r\n
HTTP request methods (i)
The HTTP request’s Method can be: GET – request information identified by
the given URI (absolute or relative?) HEAD – request metadata regarding
the given URI (search engines!) POST – send (i.e. post) information
to the given URI (e.g. via a form)
Method URI HTTP-Version\r\n
HTTP request methods (ii)
The HTTP request’s Method can be: PUT – store information in the location
identified by the given URI DELETE – remove the entity identified
by the given URI (really?)
Method URI HTTP-Version\r\n
HTTP request methods (iii)
The HTTP request’s Method can be: TRACE – used to trace HTTP forwarding
through proxies, tunnels, etc. OPTIONS – determines the capabilities of
the Web server or the characteristics of the named resource
Method URI HTTP-Version\r\n
HTTP request methods (iv)
The GET, HEAD, and POST methods are supported everywhere
HTTP 1.1 servers often supportPUT, DELETE, TRACE, andOPTIONS (but not always!)
Method URI HTTP-Version\r\n
why won’t this work?!
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
/pathwhich one should we use in our
HTTP Request-Line
?
URIs in practice
In general, relative URIs are used inthe HTTP Request-Line HTTP 1.1 servers are required to support
absolute 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)
Request headers (i)
After the Request-Line, the request might have header lines Header lines specify
attribute name/valuepairs (e.g. User-Agent:)
Note that HTTP 1.1requires the Host: header always beincluded
Request-Line
Header(s)......
-- blank line --
Content.........
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
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/htmlHost: www.rpi.eduFrom: [email protected]: Mozilla/4.0Referer: http://somewhere.else.com/rpi.html
-- blank line --
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.eduUser-Agent: SecretAgent v3.0Referer: http://somewhere.devious.com/x.phpContent-Length: 36
-- blank line --
rin=660123456&item=midterm&grade=104
HTTP response structure (i)
HTTP responses are line-based ASCII text A Status-Line is
always returned A blank line separates
the response from thecontent
Content is a sequenceof bytes (e.g. HTML,image, text, etc.)
Status-Line
Header(s)......
-- blank line --
Content.........
HTTP response structure (ii)
The Status-Line consists of 3 tokens:
The HTTP-Version is either HTTP/1.0 or 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
HTTP status codes
Status codes are grouped as follows: 1xx – Informational 2xx – Success 3xx – Redirection 4xx – Client Error 5xx – Server Error
(click me)
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
Response headers (i)
After the Status-Line, the response typically has header lines Header lines specify
attribute name/valuepairs (e.g. Date:)
As with request headers,response headers endwith a blank line
Status-Line
Header(s)......
-- blank line --
Content.........
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)
Example response headers
Headers can be included in any order:HTTP/1.1 200 OK
Date: Wed, 30 Jan 2002 12:48:17 ESTServer: Apache/1.17Content-Type: text/htmlContent-Length: 1756Content-Encoding: gzip
-- blank line --
2309fjfjef0jefe0fje2f0je2f0je2f0e2jfe0fje20fj2e0fjef0jef0e2jf0efje0fje02fje20fje2f0ejf0jef2e09fj209g209fj20gag09ha0gh0agha0gjg0jg
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!
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
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