hypertext transfer protocol {week 13 }

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

Upload: ling

Post on 19-Jan-2016

26 views

Category:

Documents


3 download

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

TRANSCRIPT

Page 1: HyperText Transfer Protocol {week  13 }

HyperText Transfer Protocol{week 13}

Rensselaer Polytechnic InstituteCSC-432 – Operating SystemsDavid Goldschmidt, Ph.D.

Page 2: HyperText Transfer Protocol {week  13 }

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

Page 3: HyperText Transfer Protocol {week  13 }

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?

Page 4: HyperText Transfer Protocol {week  13 }

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

Page 5: HyperText Transfer Protocol {week  13 }

Interprocess communication

P

Q

Page 6: HyperText Transfer Protocol {week  13 }

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

Page 7: HyperText Transfer Protocol {week  13 }

What is HTTP? (i)

From the RFC: HTTP is an application-level

protocol with the lightnessand speed necessary fordistributed, hypermediainformation systems

Page 8: HyperText Transfer Protocol {week  13 }

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

Page 9: HyperText Transfer Protocol {week  13 }

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....

Page 10: HyperText Transfer Protocol {week  13 }

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?!

Page 11: HyperText Transfer Protocol {week  13 }

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

Page 12: HyperText Transfer Protocol {week  13 }

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

Page 13: HyperText Transfer Protocol {week  13 }

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

Page 14: HyperText Transfer Protocol {week  13 }

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

Page 15: HyperText Transfer Protocol {week  13 }

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?!

Page 16: HyperText Transfer Protocol {week  13 }

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

?

Page 17: HyperText Transfer Protocol {week  13 }

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)

Page 18: HyperText Transfer Protocol {week  13 }

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.........

Page 19: HyperText Transfer Protocol {week  13 }

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

Page 20: HyperText Transfer Protocol {week  13 }

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 --

Page 21: HyperText Transfer Protocol {week  13 }

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

Page 22: HyperText Transfer Protocol {week  13 }

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.........

Page 23: HyperText Transfer Protocol {week  13 }

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

Page 24: HyperText Transfer Protocol {week  13 }

HTTP status codes

Status codes are grouped as follows: 1xx – Informational 2xx – Success 3xx – Redirection 4xx – Client Error 5xx – Server Error

(click me)

Page 25: HyperText Transfer Protocol {week  13 }

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

Page 26: HyperText Transfer Protocol {week  13 }

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.........

Page 27: HyperText Transfer Protocol {week  13 }

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)

Page 28: HyperText Transfer Protocol {week  13 }

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

Page 29: HyperText Transfer Protocol {week  13 }

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!

Page 30: HyperText Transfer Protocol {week  13 }

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

Page 31: HyperText Transfer Protocol {week  13 }

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