1 / 78

Hyper Text Transfer Protocol

Hyper Text Transfer Protocol. (HTTP). HTTP. HTTP defines how Web pages are requested and served on the Internet Early servers and browsers used an ad-hoc approach A standardized protocol, called HTTP/1.0, was derived from this The earlier approach is now called HTTP/0.9

asher
Download Presentation

Hyper Text Transfer Protocol

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. Hyper Text Transfer Protocol (HTTP)

  2. HTTP • HTTP defines how Web pages are requested and served on the Internet • Early servers and browsers used an ad-hoc approach • A standardized protocol, called HTTP/1.0, was derived from this • The earlier approach is now called HTTP/0.9 • Later, HTTP/1.0 was extended to HTTP/1.1 • The protocol versions are upwardly compatible • servers and browsers which can handle HTTP/1.1 can also handle HTTP/1.0 and HTTP/0.9

  3. History: “HTTP/0.9” • HTTP/0.9 was very simple: • A browser would send a request like this to a server: GET /hobbies.html • In response, the server would send the contents of the requested file. • Only GET requests were supported • Only a file path and name could appear in a GET request • The response had to be a HTML document.

  4. Got here on 14/jan/2003

  5. History (contd.) • Different browsers/servers soon extended this basic scheme in various ways • To achieve some standardization, the HTTP/1.0 protocol was specified, in 1996, in a document called RFC1945 • (for historical reasons, an Internet standard spec is called a Request for Comment or RFC) • This was soon extended to HTTP/1.1, in RFC2068, released in January 1997 • An update to RFC2068 was produced in June 1999, as RFC2616 • Various other protocols, based on HTTP, have been produced from time-to-time • we will see a “cookie” protocol, based on HTTP, which was specified in February 1997, in RFC2109

  6. How HTTP Works • HTTP sits on TCP, which, in turn, sits on IP • Usually, HTTP servers are configured to listen to TCP/IP Port 80 • although sometimes a different port is used, • particularly if two HTTP servers are running on one machine • You can see how HTTP works by pretending to be a browser yourself • Using telnet to connect to a server, you can issue a request and see the response

  7. Example • If you were to point a browser at the URL http://student.cs.ucc.ie you would get a HTML home-page which provides links to various pages for students, etc. • The server on student.cs.ucc.ie uses the standard HTTP port, Port 80, so you can get the same page by • telnetting to Port 80 on student.cs.ucc.ie • and typing a GET request

  8. Connecting to the HTTP server on student.cs.ucc.ie • On any machine, say interzone, specify the address and port in a telnet command: interzone.ucc.ie> telnet student.cs.ucc.ie 80 • You will get the following response: Trying 143.239.211.125... Connected to student.cs.ucc.ie. Escape character is '^]'. • The HTTP server is now listening

  9. Requesting the home page • Issue the following HTTP/1.0 request, noting that you must type two carriage returns: GET / HTTP/1.0 [RETURN] [RETURN] • The response consists of • a status line, • a sequence of headers and • the requested home page • Then you are told that the telnet connection was closed by the server, as you will see on the next slide

  10. Cs 607 got here on 14 dec 2004

  11. The reply to your request: • The server’s response: HTTP/1.1 200 OK ... Content-Type: text/html <HTML> ... </HTML> • Then your local telnet program tells you that the connection was closed by the server: Connection closed by foreign host. interzone.ucc.ie>

  12. Getting a different page: • Consider the page whose URL is http://student.cs.ucc.ie/cs1064/jabowen/ • Telnet to the server: interzone.ucc.ie> telnet student.cs.ucc.ie 80 • When the server is listening, ask for the page like this: GET /cs1064/jabowen/ HTTP/1.0 [RETURN] [RETURN]

  13. What was going on above: • Once connected to a HTTP server, we can • send a HTTP request line, • optionally followed by request headers. • In the cases above, GET / HTTP/1.0 and GET /cs1064/jabowen/ HTTP/1.0 were request lines • Each request line was terminated by pressing [RETURN] • In each case, the second [RETURN] marked the end of an empty list of request headers

  14. GET requests • In GET / HTTP/1.0 • the / is the resource the client wants to get • the HTTP/1.0 tells the server that the client is using the HTTP/1.0 protocol • In GET /cs1064/jabowen/ HTTP/1.0 • the /cs1064/jabowen/ is the resource the client wants to get • the HTTP/1.0 tells the server that the client is using the HTTP/1.0 protocol • In each case, the server responds by sending a status line, a number of response headers and the content of the requested resource.

  15. Consider the response: HTTP/1.1 200 OK ... Content-Type: text/html <HTML> ... </HTML> • The first line, HTTP/1.1 200 OK ,is a status line • The next few lines, ending in the line Content-Type: text/html, are header lines • The lines bounded by <HTML> and </HTML> form the content of the requested resource.

  16. HEAD requests • HEAD requests were new in HTTP/1.0 • A HEAD request is similar to a GET, the only difference being the use of the word HEAD instead of the word GET, for example: HEAD /cs1064/jabowen/ HTTP/1.0 [RETURN] [RETURN] • The server sends the same status line and the same response headers as if it had received a GET request, • but does not send the actual content of the resource mentioned in the request. • Thus, human clients can use HEAD requests to • access easily information about a resource on a server • without being overwhelmed by the mass of detail that would be received if the resource content were sent in the response

  17. Example HEAD request • Suppose, for example, we wanted to see information about http://student.cs.ucc.ie/cs1064/jabowen/ such as its size, when it was last edited, etc. • We can send the request HEAD /cs1064/jabowen/ HTTP/1.0

  18. Response to example HEAD request: HTTP/1.1 200 OK Date: Wed, 13 Dec 2000 12:21:35 GMT Server: Apache/1.3.14 (Unix) PHP/4.0.3pl1 Last-Modified: Thu, 07 Dec 2000 13:16:18 GMT ETag: "2160-29c6-3a2f8da2" Accept-Ranges: bytes Content-Length: 10694 Connection: close Content-Type: text/html

  19. Analysis of response: • The first line in the response HTTP/1.1 200 OK is the status line in which • HTTP/1.1 indicates that the server can use HTTP/1.1 (although it can accept requests in earlier HTTP forms) • 200 is a code which indicates the status the request was given by the server • OK is an English language phrase giving the meaning of the status code • The other lines in the response give information either about the server or the resource:

  20. Analysis (contd.) Date: Wed, 13 Dec 2000 12:21:35 GMT gives date/time of the response Server: Apache/1.3.14 (Unix) PHP/4.0.3pl1 gives details on server Last-Modified: Thu, 07 Dec 2000 13:16:18 GMT says when resource was last modified ETag: "2160-29c6-3a2f8da2" provides a supposedly-unique string to identify this entity Accept-Ranges: byte says that this server could serve up pieces of this resource, pieces specifiable to the nearest byte Content-Length: 10694 gives the size of the resource Connection: close says that the server does not regard this as a persistent connection Content-Type: text/html gives the type of data in the resource

  21. Another example • Suppose, we wanted to learn about the resource with URL http://student.cs.ucc.ie/cs1064/jabowen/vh40.gif • We can send the request HEAD /cs1064/jabowen/vh.gif HTTP/1.0 • Response is: HTTP/1.1 200 OK Date: Wed, 13 Dec 2000 12:23:04 GMT Server: Apache/1.3.14 (Unix) PHP/4.0.3pl1 Last-Modified: Fri, 24 Nov 2000 11:46:00 GMT ETag: "3133-361-3a1e54f8" Accept-Ranges: bytes Content-Length: 865 Connection: close Content-Type: image/gif

  22. Cs 607 got here on 21 Jan 2003

  23. HTTP/1.1 A (fairly) detailed description

  24. We have just seen some example HTTP/1.0 interactions • The same kinds of concepts we saw in these interactions will arise as we examine HTTP/1.1 in more detail • The versions of HTTP have a great deal in common, so, in what follows, much of what is said will be true of all three versions • Therefore,, any mention of just “HTTP” will mean that the statement applies to HTTP/0.9, HTTP/1.0 and HTTP/1.1

  25. Overall Operation of HTTP • The HTTP protocol is a request/response protocol. • request • An HTTP message sent by a client to a server • response • An HTTP message sent by a server to a client which has made a request. • client • A program that establishes connections for the purpose of sending requests. • server • A program that accepts connections in order to service requests by sending back responses. • As we shall see, a program may act as both a client and a server.

  26. Message from a client: A client sends, over a connection, to a server • a request line in the form of • a request method, • a URI (Uniform Resource Identifier), and • a protocol version, • possibly followed by a message containing • request modifiers, • information about the client, • and (possibly) body content.

  27. Response from a server: The server responds with • a status line, in the form of • the message's protocol version, • a success or error code and • an English phrase explaining the code • possibly followed by a message containing • server information, • information about the entity in the body content (if any) • and (possibly) body content.

  28. HTTP Communication • Most communication • is started by a user agent and • consists of a request to be applied to a resource on some origin server. • user agent • A client (browser, spider, etc.) which initiates a request. • resource • A data object or service that can be identified by a URI. • origin server • The server on which a resource resides or is to be created.

  29. Cs 607n got here on 11 jan 2005

  30. Simple communication • Involves single connection between user agent (UA) and origin server (O) • This connection is denoted, in diagrams on this and future slides, by ------- ====request chain ==========> UA -----------------------------------O <=========response chain====

  31. More complicated case • Intermediaries present in request/response chain. ====request chain =======================> UA ----------- A ----------- B ----------- C ----------- O <======================response chain==== • Above, 3 intermediaries (A, B, and C) lie between user agent and origin server. • Intermediaries act as both clients and servers • Request or response message that travels the whole chain passes through 4 separate connections: UA-A connection; A-B connection; B-C connection; C-O connection

  32. Simple versus complicated • Distinction is important because some HTTP options may apply • only to the connection with the nearest neighbour, • only to the end-points of the chain, • or to all connections along the chain.

  33. 3 forms of intermediary • proxy, an agent which • receives a request for a resource whose URI is in its absolute form and, • if necessary, rewrites all or part of the message and forwards the reformatted request toward the server identified by the URI. • gateway, an agent which • acts as a translation interface to a server for another protocol, such as WAP, etc. • tunnel, an agent which • acts as a relay point between two connections without changing messages; • tunnels are used, for example, in security firewalls

  34. Caching

  35. Caching • User agents, proxies and gateways (but not tunnels) may use a local cache to handle requests, instead of forwarding them on to an origin server • A request/response chain is shortened if one of the parties along the chain has a cached response applicable to the request.

  36. Example Network topology The example caching scenarios in the next few slides will use this network: UA3____________D | UA2_____ | | | | | UA1_____A______B________C_________O

  37. Caching Example 1 ====request chain ====================> UA1 ----------- A ----------- B -------- C --------- O <==================response chain===== • In the example above: • the user has made a request for a resource on origin server O • neither UA1 nor any of the proxies A, B or C has an appropriate cached response • so the request has been forwarded all the way to O • Four connections are involved in servicing the request

  38. Caching Example 2 request chain UA1…………….... A ……... B …….. C …… O response chain • In the example above: • the user has repeated the same request for a resource on O • UA1 has a cached response to the earlier request and gives this to the user without sending the request anywhere • No connection is involved in servicing the request

  39. Caching Example 3 ===request chain => UA2 ----------------- UA1 …..……...... A …….. B …….. C ……... O <=response chain== • In the example above: • the user at UA2 has requested the same resource on origin server O that was earlier requested by the user at UA1 • UA2 has forwarded the request to proxy A • proxy A has an appropriate cached response, from when it serviced the earlier request from UA1 • Only one connection is involved in servicing the request

  40. Caching Example 4 ===request chain ====> UA3 ---------- D -------- | UA1 …..…... A …….. B …….. C ……... O <===response chain=== • In the example above: • the user at UA3 has requested the same resource on origin server O that was earlier requested by the user at UA1 • UA3 has forwarded the request to proxy D, which has forwarded it to proxy B • proxy B has an appropriate cached response, from when it serviced the earlier request from UA1 • Two connections are involved in servicing the request

  41. To cache or not? • Not all responses are usefully cacheable • As we will see later, some requests may contain modifiers which place special requirements on cache behavior. • The same is true of responses

  42. Cs 607 ngot here on 28 january 2003

  43. Caching/Proxy architectures • A wide variety of cache and proxy architectures/configurations exist, including: • national hierarchies of proxy caches to save inter-national and/or inter-continental bandwidth, • systems that broadcast or multicast cache entries, • organizations that distribute subsets of cached data via CD-ROM, • and so on.

  44. Connections

  45. Temporary Connections • In most implementations of HTTP/1.0, a server closed a connection after it had serviced the request received on that connection: • We saw this earlier, when the server on student.cs.ucc.ie closed the telnet connection that we had established, after it had sent its response to the HTTP/1.0 GET request we had sent • The use of inline images, sound files, etc., in web pages often requires a client to make multiple requests of the same server when loading one document • Thus the temporary connections provided by HTTP/1.0 meant that loading even one web page required many separate TCP connections (one to to fetch each inline image, each sound file etc.) • This imposed a significant unnecessary load on HTTP servers and caused congestion on the Internet.

  46. Advantages of Persistent Connections Persistent HTTP connections offer a number of advantages: • By opening and closing fewer TCP connections, CPU time is saved • HTTP requests and responses can be pipelined on a connection, allowing a client to make multiple requests without waiting for each response • Network congestion is reduced by reducing the number of packets caused by TCP opens, • Latency on subsequent requests is reduced since there is no time spent in TCP's connection-opening handshake.

  47. Persistent Connections in HTTP/1.1 • Unlike HTTP/1.0 and earlier, persistent connections are the default behavior of any HTTP/1.1 connection. • This means that, in HTTP/1.1, when a connection has been opened to service a request, it is kept open for further possible requests from the same client • This is true even if the initial request triggered an error response from the server • But, when no further request has been received after some time-out period, the server may close the connection • However, a client can indicate, when making a request, that it wants the connection closed after the request is serviced

  48. Connection Persistency Negotiation • HTTP/1.1 provides a mechanism by which a client and a server can signal the close of a TCP connection. • the Connection: header field. • If a HTTP/1.1 client wants a connection closed after it receives a response to its request, it should include, in the request, a Connection: header containing the token "close" . • Similarly, if a HTTP/1.1 server intends to close a connection closed after it sends a response to a request, it should include, in the response, a Connection: header containing the token "close" . • If either the client or the server sends the close token in a Connection: header, that request becomes the last one for the connection.

  49. Example 1: Introduction • A human, using a telnet client, sends a HTTP/1.0 request to a HTTP/1.1 server • The server assumes that the client, because it is using HTTP/1.0, cannot handle persistent connections and, in its response, signals its intention to close the connection • After printing the response, the telnet client says that the connection was closed by the foreign host

  50. Example 1 interzone.ucc.ie> telnet student.cs.ucc.ie 80 Trying 143.239.211.125... Connected to student.cs.ucc.ie. Escape character is '^]'. HEAD /cs1064/jabowen/ HTTP/1.0 HTTP/1.1 200 OK Date: Sat, 06 Jan 2001 17:56:44 GMT Server: Apache/1.3.14 (Unix) PHP/4.0.3pl1 Last-Modified: Wed, 20 Dec 2000 11:34:46 GMT ETag: "2160-2dee-3a409956" Accept-Ranges: bytes Content-Length: 11758 Connection: close Content-Type: text/html Connection closed by foreign host.

More Related