Superglobals and Cookies

  • The web server in Problem Set 6 demonstrates writing software that knows how to take HTTP requests from a browser (or a human with a program called telnet), and respond to those requests with an HTML, JPG, or PHP file.

  • But a web server shouldn’t return a raw PHP file, but interpret it first.

    • It notices that it ends in .php, so it interprets it line by line, using a pre-existing program, PHP (which happens to have the same name as the language it interprets).

  • We took care of that part for you in Problem Set 6, so all you had to do was support static content, among other things.

  • In Problem Set 7, we’ll start to write the PHP code that gets interpreted, talking to the back-end database that stores our information.

  • Remember from last time that we have these superglobals:

    • $_COOKIE

    • $_GET

    • $_POST

    • $_SERVER

    • $_SESSION

    • …​

  • On Monday we used $_GET, which had all the parameters we put in the query string. When we implemented our own version of Google, the URL had a question mark and then q= (like The question mark indicated the start of the query string q=cats, and $_GET would automatically have a key named q with the value cats.

  • All of these superglobals are associative arrays, or hash tables that store keys and values.

  • In Problem Set 5, the hash table or trie you implemented was really an associative array where the keys were associated with values of true or false, whether the word was in the dictionary or not.

  • But we can associate more interesting values with keys, and return arbitrary strings, which is what $_GET and these other variables allow us to do.

  • $_POST stores forms sent by the POST method, and files are actually stored in a variable not listed, $_FILES.

  • $_SERVER gives you details about the server, which we won’t go into detail about.

  • $_COOKIE and $_SESSION are what we need to implement things like a simple shopping cart.

  • Last time we had an example of a counter.php file that counted how many times we visited the page:

  • We can open Chrome’s Developer Tools, but first clear the cache:

    Opening the History page in Chrome
    Clearing the cache
    Choosing a time span
  • We’ll do this for debugging purposes, getting rid of cookies, a piece of data that a server asks to put on your computer, to remember who you are.

  • After you log into a website like Gmail or Facebook, the server remembers that you are logged in, even though you’re not typing in your username and password at every page. Cookies are the answer. They are like a digital handstamp that you might get at an amusement park or club, that indicates you’ve already showed your ID, and have been identified already.

  • We can reload counter.php and view the request as we’ve done before (clicking view source next to Request Headers to see the raw request):

    counter.php Request Headers
    • In Problem Set 6 we’ve familiarized ourselves with lines like GET /counter.php HTTP/1.1, so not much new here.

  • But if we scroll down to Response Headers and click view source, we see: