Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
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
2: Application Layer 2
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)
2: Application Layer 3
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
2: Application Layer 4
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
2: Application Layer 5
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
2: Application Layer 6
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
2: Application Layer 7
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
2: Application Layer 8
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
2: Application Layer 9
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
2: Application Layer 10
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
2: Application Layer 11
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
2: Application Layer 12
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
2: Application Layer 13
HTTP request message: general format
2: Application Layer 14
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
2: Application Layer 15
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
2: Application Layer 16
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
2: Application Layer 17
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
2: Application Layer 18
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
2: Application Layer 19
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!
2: Application Layer 20
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
2: Application Layer 21
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
2: Application Layer 22
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)
2: Application Layer 23
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
2: Application Layer 24
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
2: Application Layer 25
New headers: Response
Redirection:Old: Location
InformationOld: ServerNew: Retry-After, Accept-Ranges
Security relatedOld: WWW-AuthenticateNew: Proxy-Authenticate
Caching relatedNew: Etag, Age, Vary
2: Application Layer 26
New headers: Entity
Old:AllowContent-Encoding, -Length, -TypeExpiresLast-Modified
New:Content-Language, -Location, -MD5, -Range
2: Application Layer 27
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, …
2: Application Layer 28
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
2: Application Layer 29
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
2: Application Layer 30
Cookies: keeping “state” (cont.)
client serverusual http request msgusual http response +Set-cookie: 1678
usual http request msgcookie: 1678
usual http response msg
usual http request msgcookie: 1678
usual http response msg
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
2: Application Layer 31
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)
2: Application Layer 32
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>