1. HTTP Transactions 1

2. 2 Client-Server Model

3. 3 HTTP HyperText Transport Protocol Native protocol for WWW Sits on top of internet’s TCP/IP protocol HTTP is a 4 step process per transaction Uses a predefined set of document formats from MIME

4. 4 MIME Multipurpose Internet Mail Extensions – defines file formats (images, video, text, etc) – e.g. Content-type: text/html – Data type/subtype » text/html » text/plain » image/gif » video/mpeg » application/msword etc

5. 5 HTTP Connection 1. Client – Makes an HTTP request for a web page – Makes a TCP/IP connection 2. Server accepts request – Sends page as HTTP 3. Client downloads page 4. Server breaks the connection

6. 6 HTTP is Stateless Each operation or transaction makes a new connection each operation is unaware of any other connection Each click is a new connection So how do they do those shopping carts?

7. 7 HTTP Transaction Example All web communications use HTTP protocol. HTTP consists of two phases. The Request Phase The Response Phase

8. 8 Examining HTTP Header Values In PHP – $_SERVER is an array containing information such as headers, paths, and script locations

9. 9 Understanding STATUS Codes 1xx – for information only 2xx – action successful 3xx – further action needed (redirect) 4xx – client request error 5xx – server error

10. 10 HTTP Transaction 1.Client and server establish a connection 2.Client makes a request 3.Server makes a response 4.Server terminates connection

11. HTTP protocol - Stateless HTTP is stateless. In other words, between each request made from a browser to a webserver, the webserver completely forgets anything about any previous requests (i.e. it doesn't preserve state--or memory, after a request has been fulfilled). The stateless model works well for static HTML sites. But often an application may need some form of server-side state in order to remember things like: who's currently logged in, what a visitor has put in their shopping cart, user’s preferences etc. 11

12. HTTP protocol - Methods of Preserving State on top of HTTP There are three common ways to preserve state across a multi-page website visit (or "session"): – hidden form fields, URL rewriting, and browser cookies. In each of these techniques, the webserver sends the browser some information (the current state) embedded into each HTML document that is returned to the browser. This information is encoded in such a way that every subsequent request from the browser sends this information back to the webserver so that it can identify and recognize the request as belonging to an existing session. 12

13. Methods of Preserving State on top of HTTP – Hidden Form Fields This technique relies upon the type="hidden" attribute value of an HTML form's tag. The web application will add the browser's current state (name & value pairs) to one or more tags and then when the form is POSTed back to the webserver, this state information is sent back as well. Advantages: Does not require any special support from the server-side scripting platform. No browser cookies. Disadvantages: The hidden form fields don't work so well for links, which have no tags. In these cases, the web application will have to produce href attribute values that incorporate the state name and value pairs into the query string that is appended to the corresponding GET request. The application developer is responsible for generating code to write these state variables into each and every HTML form or link. 13

14. Methods of Preserving State on top of HTTP – URL Rewriting URL rewriting is similar to the hidden form field technique, instead this time, the server-side platform (e.g. PHP) does the work of inserting the hidden form fields or rewriting each link's query string to accommodate the added state information. The advantages of URL Rewriting are the same as in the case of hidden form fields, and the disadvantage of extra work on the part of the application developer is dispensed with. However, the URLs still end up looking messy (and visible to the person sitting at the browser), and sensitive information sent through HTTP GET is still logged by webservers The default installation of PHP uses this technique (in addition to cookies) for the first page of a site that requires state. If the browser refuses to send back a cookie, PHP will continue to use URL Rewriting unless configured not to. 14

15. Methods of Preserving State on top of HTTP – Browser Cookies A browser cookie (the term was first coined by Netscape) is nothing more than a text string that is no more than 4KB in size. A browser cookie is sent from webserver to browser by adding the field "Set-Cookie" to the HTTP response header, and is sent from the browser to the webserver by adding the field "Cookie" to the HTTP GET or POST header. Aside from name/value pairs used to record the state information, browser cookies have a number of attributes: domain (a browser will only send a cookie to a webserver if its domain matches the website's URL), directory path (a browser will only send a cookie to a webserver if its directory path is under that of the requested page's path), expiry date (the date and time past which the browser should not send the cookie), and a secure attribute to indicate that the cookie's payload (state information) is encrypted through SSL. 15

16. Browser Cookies – Scenario details Client (Browser) Requests a file, say first.php from the webserver by sending a GET command. The browser displays the returned HTML document, and stores the cookie (on disk, sometimes in memory). On the displayed HTML document, a link to second.php is clicked by the user. The browser sends the request for the document using the GET command and also sends the cookie back to the server (assuming both the cookie's domain and path attributes are compatible) by adding a Cookie directive to the HTTP request header. Server (Web Server) Responds to the request by sending the HTML rendered from the first.php file. It also adds a Set-Cookie directive to the HTTP response header. The Set-Cookie directive contains all of the cookie parameters, as well as the state information. Receives the request, notes the presence of the cookie, and loads the state information from it. This information is available to the second.php as it is interpreted, and finally the resulting HTML is sent back to the browser. 16

17. Session Management The idea is simply to identify and distinguish every visitor to a website, and maintain that information as the visitor moves from page to page throughout the site. You need some method of preserving state to maintain information. Therefore, one of the three methods will have to be used, but instead of transmitting all of the state variables back and forth between browser and webserver, only a unique string or number that identifies that particular session will be transmitted. Upon receipt of this identifier, the webserver will look up and load that session's corresponding state information. Most server-side scripting platforms include features to: simplify the management of these sessions, generate the session identifier (called a "session ID" or a "session key"), load and store the state information as needed, and automatically purge the session from memory after a certain period has elapsed without activity from the associated browser (in order to free webserver resources). 17

18. Session Management -Advantages Support for multi-page User Interfaces. Most web applications use many separate pages that together are required to perform a task. As a visitor transits through these multiple pages, the actions taken on the previous pages must be recorded somewhere so that the information is not lost as the visitor arrives at the final page. 18

19. Session Management -Disadvantages Performance. Many pages on the site may not need the session information, but the server-side scripting platform must load this regardless with every page visit. Centralized Session Store. All session state must be stored in a single centralized space (most likely a database) for a website. The DB can become both a single point of failure, and a single point of contention as well. Indeterminate Session Length and time-outs. Webservers must arbitrarily end sessions after a certain elapsed time (time-out), since there is no way of knowing if a user has terminated a session or not. On a time-out,, state is lost, and if the visitor later returns, he or she will have to manually restore their session state. Bookmark Problems. If a visitor bookmarks a page on a web application, upon their return they may not have the required session state (presuming the session expired previously) to reach that page. 19

20. Session Management in PHP PHP (4.0 onwards) includes a great deal of support for session management. Built-in functions help maintain session state for your web applications. By default, PHP uses browser cookies to preserve state. However, PHP can't detect whether cookies are enabled on the browser until the browser sends the cookie back to the webserver in an HTTP request header. Therefore, PHP uses URL rewriting on the first page of a website that requires session management, and if a cookie is returned on the next page request, abandons the URL rewriting in favour of cookies. If the cookie is not returned, PHP continues using URL rewriting. It's possible to configure PHP to use just cookies, or just URL rewriting. 20

21. Session Management in PHP Starting a Session: To use sessions, you must include the following line in every page of your web application: session_start(); 21

22. Session Management in PHP Stopping a Session To explicitly stop or end a session, the following two lines are necessary: $_SESSION = array(); session_destroy(); The first statement empties out the built-in session state associative array. The second statement ends the session, and destroys any state stored on the webserver. 22

23. Session Management in PHP Reading and Writing Session State Variables All session state is stored in the built-in $_SESSION associative array. For example, if you decide to store the current user ID from the database (say, 12345) in session state, you might do the following: $_SESSION[‘some'] = 12345; To print out that value later on in the session, perhaps on a different page, you'd use: print $_SESSION[‘some']; You can use the isset() function to find out (actually, isset() works for any variable or associative array element): if (isset($_SESSION[‘some'])) {...} A shortcut for retrieving the value of a session variable that might not yet be defined uses the ternary operator: Finally, to retrieve the value of the current session key, use the session_id() function. 23