HTTP - timeline · 2: Application Layer 1 HTTP - timeline Mar 1990 CERN labs document proposing Web...

2: Application Layer 1

HTTP - timelineMar 1990 CERN labs document proposing WebJan 1992 HTTP/0.9 specificationDec 1992 Proposal to add MIME to HTTPFeb 1993 UDI (Universal Document Identifier) NetworkMar 1993 HTTP/1.0 first draftJun 1993 HTML (1.0 Specification)Oct 1993 URL specificationNov 1993 HTTP/1.0 second draftMar 1994 URI in WWWMay 1996 HTTP/1.0 Informational, RFC 1945Jan 1997 HTTP/1.1 Proposed Standard, RFC 2068Jun 1999 HTTP/1.1 Draft Standard, RFC 26162001 HTTP/1.1 Formal Standard


MIME and HTTP

Original proposalAll resources MIME encapsulated

Web should only handle MIME-complient data

AdoptedClassification of data formats (MIME types)Formats for multipart messages

Not adoptedRich text markup mechanism (rather used HTML)Addressing external documents (rather used URLs)


MIME and HTTP differences

MIME defined for e-mailHTTP high performanceInterpretation of header fields (content-

length)Limitation on line lengthHTTP is not MIME-compliant (content-

encoding)Different kinds of entities


HTTP and Objects

First some jargonWeb page consists of objectsObject can be HTML file, JPEG image, Java applet, audio file,…Web page consists of base HTML-file which includes several referenced objectsEach object is addressable by a URLExample URL:

www.someschool.edu/someDept/pic.gif

host name path name


HTTP overview

HTTP: hypertext transfer protocolWeb’s application layer protocolclient/server model

client: browser that requests, receives, “displays” Web objectsserver: Web server sends objects in response to requests

HTTP 1.0: RFC 1945HTTP 1.1: RFC 2068

PC runningExplorer

Server running

Apache Webserver

HTTP request

HTTP request

HTTP response

HTTP response

Mac runningNavigator


HTTP overview (continued)

HTTP is “stateless”server maintains no information about past client requests

Uses TCP:client initiates TCP connection (creates socket) to server, port 80server accepts TCP connection from clientHTTP messages (application-layer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server)TCP connection closed

Protocols that maintain “state” are complex!past history (state) must be maintainedif server/client crashes, their views of “state” may be inconsistent, must be reconciled

aside


HTTP connections

Persistent HTTPMultiple objects can be sent over single TCP connection between client and server.HTTP/1.1 uses persistent connections in default mode

Nonpersistent HTTPAt most one object is sent over a TCP connection.HTTP/1.0 uses nonpersistent HTTP


Nonpersistent HTTP(contains text,

references to 10 jpeg images)

Suppose user enters URL www.someSchool.edu/someDepartment/home.index

1a. HTTP client initiates TCP connection to HTTP server (process) at www.someSchool.edu on port 80

2. HTTP client sends HTTP request message (containing URL) into TCP connection socket. Message indicates that client wants object someDepartment/home.index

1b. HTTP server at host www.someSchool.edu waiting for TCP connection at port 80. “accepts” connection, notifying client

3. HTTP server receives request message, forms response message containing requested object, and sends message into its socket

time


Nonpersistent HTTP (cont.)

4. HTTP server closes TCP connection.

time

5. HTTP client receives response message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects

6. Steps 1-5 repeated for each of 10 jpeg objects


Response time modelingDefinition of RRT: time to

send a small packet to travel from client to server and back.

Response time:one RTT to initiate TCP connectionone RTT for HTTP request and first few bytes of HTTP response to returnfile transmission time

total = 2RTT+transmit time

time to transmit file

initiate TCPconnection

RTT

requestfile

RTT

filereceived

time time


Persistent HTTP

Nonpersistent HTTP issues:requires 2 RTTs per objectOS must work and allocate host resources for each TCP connectionbut browsers often open parallel TCP connections to fetch referenced objects

Persistent HTTPserver leaves connection open after sending responsesubsequent HTTP messages between same client/server are sent over connection

Persistent without pipelining:client issues new request only when previous response has been receivedone RTT for each referenced object

Persistent with pipelining:default in HTTP/1.1client sends requests as soon as it encounters a referenced objectas little as one RTT for all the referenced objects


HTTP request message

two types of HTTP messages: request, responseHTTP request message:

ASCII (human-readable format)

GET /somedir/page.html HTTP/1.1Host: www.someschool.eduUser-agent: Mozilla/4.0Connection: close Accept-language:fr

(extra carriage return, line feed)

request line(GET, POST,

HEAD commands)

headerlines

Carriage return, line feed

indicates end of message


HTTP request message: general format


Uploading form input

Post method:Web page often includes form inputInput is uploaded to server in entity body

URL method:Uses GET methodInput is uploaded in URL field of request line:

www.somesite.com/animalsearch?monkeys&banana


Method types

HTTP/1.0GETPOSTHEAD

asks server to leave requested object out of response

HTTP/1.1GET, POST, HEADPUT

uploads file in entity body to path specified in URL field

DELETEdeletes file specified in the URL field


HTTP response message

HTTP/1.1 200 OK Connection closeDate: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html

data data data data data ...

status line(protocol

status codestatus phrase)

headerlines

data, e.g., requestedHTML file


HTTP response status codesIn first line in server->client response message.A few sample codes:

200 OKrequest succeeded, requested object later in this message

301 Moved Permanentlyrequested object moved, new location specified later in this message (Location:)

400 Bad Requestrequest message not understood by server

404 Not Foundrequested document not found on this server

505 HTTP Version Not Supported


HTTP/1.0 response classes?From SMTP reply codes (yet no specificmeaning)X00: default response1XX: Informational2XX: Success200 OK, 201 Created, 202 Accepted, 204 No Content3XX: Redirection300 Multiple Choices, 301 Moved Permanently, 302 Moved Temporarily, 304 Not

Modified4XX: Client error400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found5XX: Server error500 Internal Server Error 502 Not Implemented


Trying out HTTP (client side) for yourself

1. Telnet to your favorite Web server:Opens TCP connection to port 80(default HTTP server port) at www.eurecom.fr.Anything typed in sent to port 80 at www.eurecom.fr

telnet www.eurecom.fr 80

2. Type in a GET HTTP request:By typing this in (hit carriagereturn twice), you sendthis minimal (but complete) GET request to HTTP server

GET /~ross/index.html HTTP/1.0

3. Look at response message sent by HTTP server!


Problems with HTTP/1.0

Lack of control: cache duration, cache location,selection among cached variants, …Ambiguity of rules for proxies and cachesDownload of full resource instead of needed partPoor use of TCP: short Web responsesNo guarantee for full receipt for dynamically

generated responsesDepletion of IP addressesInability to tailor request, responses according to

client, server preferencePoor level of securityMiscellaneous


New conceptsHop-by-hop mechanism

Headers valid only for a single transport-level connection:

Transfer-Encoding, ConnectionCannot be stored by caches or forwarded by proxies

Transfer codingSplit: message vs. entity (including headers)Content coding is applied to whole entityTransfer coding applies to entity-body• Property of message not original entity• TE, Transfer-Encoding

Virtual hostingSemantic transparency for cachingSupport for variants of a resource


HTTP/1.1 methodsGET, HEAD, POSTPUT, DELETE: formalizedOPTIONS: purpose extensibility

Learn about a server’s capabilityLearn about intermediate servers in the path (Max-

Forwardsheader == TTL)

TRACE: purpose extensibilityReturns the content of the message from the

receiver (Viaheader == records intermediaries)

CONNECT: future use(extensibility: Upgrade header allows switch to otherprotocols)


New headers: General

Old:Date, Pragma

New:Cache-Control CachingConnection Hop-by-hopTrailer List of headers at endTransfer-Encoding Transformation to message

bodyUpgrade Upgrade to other protocolsVia Intermediate serversWarning Error-notification


New headers: Request

Response preferenceNew: Accept (charset, encoding, language), TE

InformationOld: Authorization, From, Referer, User-AgentNew: Proxy-Authorization

Conditional requestOld: If-Modified-SinceNew: If-Match, If-None-Match, If-Unmodified-Since, If-Range

Constraint on serverNew: Expect, Host, Max-Forwards, Range


New headers: Response

Redirection:Old: Location

InformationOld: ServerNew: Retry-After, Accept-Ranges

Security relatedOld: WWW-AuthenticateNew: Proxy-Authenticate

Caching relatedNew: Etag, Age, Vary


New headers: Entity

Old:AllowContent-Encoding, -Length, -TypeExpiresLast-Modified

New:Content-Language, -Location, -MD5, -Range


Response codes: ExamplesInformational

100 Continue, 101 Switching ProtocolsSuccess: 206 Partial Content, …Redirection: 305 Use Proxy, …Client errors

14 new onesError codes: 400 bad request, 404 not foundClarification status codes: 405 method not allowed, 410

goneUsing negotiation: 406 not acceptable, 412 unsupported

mediatype

Length related: 411 length requiredOther features: 402 Payment Required, 417 expectation

failedServer errors: 504 gateway Timeout, …


User-server interaction: authorizationAuthorization : control access to

server contentauthorization credentials: typically name, passwordstateless: client must present authorization in each request

authorization: header line in each requestif no authorization: header, server refuses access, sendsWWW authenticate:

header line in response

serverclientusual http request msg401: authorization req.WWW authenticate:

usual http request msg+ Authorization: <cred>

usual http response msg

usual http request msg+ Authorization: <cred>

usual http response msg time


Cookies: keeping “state”

Many major Web sites use cookies

Four components:1) cookie header line in

the HTTP response message

2) cookie header line in HTTP request message

3) cookie file kept on user’s host and managed by user’s browser

4) back-end database at Web site

Example:Susan access Internet always from same PCShe visits a specific e-commerce site for first timeWhen initial HTTP requests arrives at site, site creates a unique ID and creates an entry in backend database for ID


Cookies: keeping “state” (cont.)

client serverusual http request msgusual http response +Set-cookie: 1678

usual http request msgcookie: 1678


usual http request msgcookie: 1678


cookie-specificaction

cookie-spectific

action

servercreates ID

1678 for user

entry in backend

database

access

access

Cookie file

ebay: 8734

Cookie file

amazon: 1678ebay: 8734

one week later:

Cookie file

amazon: 1678ebay: 8734


Cookies (continued)Cookies and privacy:

cookies permit sites to learn a lot about youyou may supply name and e-mail to sitessearch engines use redirection & cookies to learn yet moreadvertising companies obtain info across sites

asideWhat cookies can bring:

authorizationshopping cartsrecommendationsuser session state (Web e-mail)


Conditional GET: client-side caching

serverclientGoal: don’t send object if client has up-to-date cached versionclient: specify date of cached copy in HTTP requestIf-modified-since:

<date>

server: response contains no object if cached copy is up-to-date: HTTP/1.0 304 Not

Modified

HTTP request msgIf-modified-since:

<date> object not

modifiedHTTP responseHTTP/1.0

304 Not Modified

HTTP request msgIf-modified-since:

<date> object modified

HTTP responseHTTP/1.0 200 OK

<data>

HTTP - timeline · 2: Application Layer 1 HTTP - timeline Mar 1990 CERN labs document proposing Web...

Documents

Transcript of HTTP - timeline · 2: Application Layer 1 HTTP - timeline Mar 1990 CERN labs document proposing Web...