031.3 Μάθημα 1

Πιστοποιητικό:

Web Development Essentials

Έκδοση:

1.0

Θέμα:

031 Ανάπτυξη Λογισμικού και Web Τεχνολογίες

Σκοπός:

031.3 Βασικά Στοιχεία HTTP

Μάθημα:

1 απο 1

Εισαγωγή

Το HyperText Transfer Protocol (HTTP) ορίζει πώς ένας client ζητά από τον server έναν συγκεκριμένο πόρο. Η αρχή λειτουργίας του είναι αρκετά απλή: ο client δημιουργεί ένα μήνυμα αιτήματος που προσδιορίζει τον πόρο που χρειάζεται και προωθεί αυτό το μήνυμα στον server μέσω του δικτύου. Με τη σειρά του, ο HTTP server αξιολογεί πού θα εξάγει τον ζητούμενο πόρο και στέλνει ένα μήνυμα απάντησης πίσω στον client. Το μήνυμα της απάντησης περιέχει λεπτομέρειες σχετικά με τον ζητούμενο πόρο, ακολουθούμενο από τον ίδιο τον πόρο.

Πιο συγκεκριμένα, το HTTP είναι το σύνολο κανόνων που καθορίζουν τον τρόπο με τον οποίο η client εφαρμογή θα πρέπει να μορφοποιεί τα μηνύματα των αιτημάτων [request] που θα αποστέλλονται στον server. Στη συνέχεια, ο server ακολουθεί τους κανόνες του HTTP για να ερμηνεύσει το αίτημα και να μορφοποιήσει τα μηνύματα των απαντήσεων [reply]. Εκτός από το αίτημα ή τη μεταφορά του ζητούμενου περιεχομένου, τα HTTP μηνύματα περιέχουν επιπλέον πληροφορίες για τον client και τον server που εμπλέκονται, για το ίδιο το περιεχόμενο, ακόμη και για τη μη διαθεσιμότητά του. Εάν δεν είναι δυνατή η αποστολή ενός πόρου, ένας κωδικός στην απάντηση εξηγεί τον λόγο της μη διαθεσιμότητας και, εάν είναι δυνατόν, υποδεικνύει πού μετακινήθηκε ο πόρος.

Το τμήμα του μηνύματος που ορίζει τις λεπτομέρειες του πόρου και άλλες πληροφορίες στο πλαίσιο αυτό, ονομάζεται header [κεφαλίδα] του μηνύματος. Το τμήμα που ακολουθεί το header, το οποίο περιέχει το περιεχόμενο του αντίστοιχου πόρου, ονομάζεται payload [ωφέλιμο φορτίο] του μηνύματος. Τόσο τα μηνύματα αιτήματος όσο και τα μηνύματα απάντησης μπορεί να έχουν payload, αλλά στις περισσότερες περιπτώσεις, μόνο το μήνυμα απάντησης έχει ένα.

Aίτημα του Client

Το πρώτο στάδιο μιας ανταλλαγής δεδομένων HTTP μεταξύ του client και του server ξεκινά από τον πελάτη, όταν γράφει ένα μήνυμα αιτήματος προς τον server. Πάρτε, για παράδειγμα, μια κοινή εργασία ενός προγράμματος περιήγησης: να φορτώσετε μια σελίδα HTML από έναν server που φιλοξενεί έναν ιστότοπο, όπως https://learning.lpi.org/en/. Η διεύθυνση ή η URL παρέχει πολλές σχετικές πληροφορίες. Τρεις πληροφορίες εμφανίζονται σε αυτό το συγκεκριμένο παράδειγμα:

Το πρωτόκολλο: HyperText Transfer Protocol Secure (https), μια κρυπτογραφημένη έκδοση του HTTP.
To όνομα δικτύου του διαδικτυακού host (learning.lpi.org)
Την τοποθεσία του ζητούμενου πόρου στον server (ο κατάλογος /en/--η αγγλική έκδοση της αρχικής σελίδας σε αυτήν την περίπτωση).

Note

Ένα Uniform Resource Locator (URL) είναι μια διεύθυνση που υποδεικνύει σε έναν πόρο στο Διαδίκτυο. Αυτός ο πόρος είναι συνήθως ένα αρχείο που μπορεί να αντιγραφεί από έναν απομακρυσμένο server, αλλά οι διευθύνσεις URL μπορούν επίσης να υποδεικνύουν δυναμικά δημιουργημένο περιεχόμενο και ροές δεδομένων.

Πως Χειρίζεται την URL ο Client

Πριν επικοινωνήσει με τον server, ο client πρέπει να μετατρέψει το learning.lpi.org στην αντίστοιχη IP διεύθυνσή του. Ο client χρησιμοποιεί μια άλλη υπηρεσία του Διαδικτύου, το Domain Name System (DNS), για να ζητήσει τη διεύθυνση IP ενός ονόματος host από έναν ή περισσότερους προκαθορισμένους DNS servers (οι DNS servers συνήθως ορίζονται αυτόματα από τον Internet Service Provider, ISP).

Με τη διεύθυνση IP του server, ο client προσπαθεί να συνδεθεί στη HTTP ή HTTPS port [θύρα]. Τα δικτακά ports είναι αριθμοί αναγνώρισης που ορίζονται από το Transmission Control Protocol (TCP) για τη διασύνδεση και τον εντοπισμό διακριτών καναλιών επικοινωνίας σε μια σύνδεση client/server. Από προεπιλογή, οι HTTP servers λαμβάνουν αιτήματα στα ports TCP 80 (HTTP) και 443 (HTTPS).

Note

Υπάρχουν άλλα πρωτόκολλα που χρησιμοποιούνται από web εφαρμογές για την υλοποίηση της επικοινωνίας client/server. Για κλήσεις ήχου και βίντεο, για παράδειγμα, είναι πιο κατάλληλο να χρησιμοποιείτε το WebSockets, ένα πρωτόκολλο χαμηλότερου επιπέδου που είναι πιο αποτελεσματικό από το HTTP για τη μεταφορά ροών δεδομένων και προς τις δύο κατευθύνσεις.

Η μορφή του μηνύματος αιτήματος που στέλνει ο client στον server είναι η ίδια σε HTTP και HTTPS. Το HTTPS χρησιμοποιείται ήδη ευρύτερα από το HTTP, επειδή όλες οι ανταλλαγές δεδομένων μεταξύ client και server είναι κρυπτογραφημένες, κάτι που είναι απαραίτητο χαρακτηριστικό για την προώθηση του απορρήτου και της ασφάλειας στα δημόσια δίκτυα. Η κρυπτογραφημένη σύνδεση δημιουργείται μεταξύ client και server, ακόμη και πριν από την όποια ανταλλαγή του HTTP μηνύματος, χρησιμοποιώντας το κρυπτογραφικό πρωτόκολλο Transport Layer Security (TLS). Με αυτόν τον τρόπο, όλη η HTTPS επικοινωνία περικλείεται από το TLS. Μόλις αποκρυπτογραφηθεί, το αίτημα ή η απάντηση που μεταδίδεται μέσω HTTPS δεν διαφέρει από ένα αίτημα ή απάντηση που γίνεται αποκλειστικά μέσω HTTP.

Το τρίτο στοιχείο της URL μας, /en/, θα ερμηνευτεί από τον server ως η τοποθεσία ή το μονοπάτι για τον πόρο που ζητείται. Εάν το μονοπάτι δεν παρέχεται στη URL, θα χρησιμοποιηθεί η προεπιλεγμένη τοποθεσία /. Η απλούστερη υλοποίηση ενός HTTP server συσχετίζει μονοπάτια σε URLs με αρχεία στο σύστημα αρχείων όπου τρέχει ο server, αλλά αυτή είναι μόνο μία από τις πολλές επιλογές που είναι διαθέσιμες σε πιο εξελιγμένους HTTP server.

Το Μήνυμα Αιτήματος

Το HTTP λειτουργεί μέσω μιας σύνδεσης που έχει ήδη δημιουργηθεί μεταξύ client και server, που συνήθως υλοποιείται σε TCP και κρυπτογραφείται με TLS. Στην πραγματικότητα, μόλις μια σύνδεση που πληροί τις απαιτήσεις που επιβάλλονται από τον server είναι έτοιμη, ένα HTTP αίτημα που πληκτρολογείται με το χέρι σε απλό κείμενο θα μπορούσε να δημιουργήσει την απάντηση από τον server. Στην πράξη, ωστόσο, οι προγραμματιστές σπάνια χρειάζεται να εφαρμόσουν ρουτίνες για τη σύνταξη HTTP μηνυμάτων, καθώς οι περισσότερες γλώσσες προγραμματισμού παρέχουν μηχανισμούς που αυτοματοποιούν τη δημιουργία του HTTP μηνύματος. Στην περίπτωση του παραδείγματος URL, https://learning.lpi.org/en/, το απλούστερο δυνατό μήνυμα αιτήματος θα έχει το ακόλουθο περιεχόμενο:

GET /en/ HTTP/1.1
Host: learning.lpi.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0
Accept: text/html

Η πρώτη λέξη της πρώτης γραμμής προσδιορίζει τη μέθοδο HTTP. Καθορίζει ποια λειτουργία θέλει να εκτελέσει ο client στον server. Η μέθοδος GET ενημερώνει τον server ότι ο client ζητά τον πόρο που την ακολουθεί: /en/. Τόσο ο client όσο και ο server ενδέχεται να υποστηρίζουν περισσότερες από μία εκδόσεις του πρωτοκόλλου HTTP, επομένως η έκδοση που θα υιοθετηθεί στην ανταλλαγή δεδομένων παρέχεται επίσης στην πρώτη γραμμή: HTTP/1.1.

Note

Η πιο πρόσφατη έκδοση του πρωτοκόλλου HTTP είναι η HTTP/2. Μεταξύ άλλων διαφορών, τα μηνύματα που είναι γραμμένα σε HTTP/2 κωδικοποιούνται σε binary δομή, ενώ τα μηνύματα γραμμένα σε HTTP/1.1 αποστέλλονται σε απλό κείμενο. Αυτή η αλλαγή βελτιστοποιεί τους ρυθμούς μετάδοσης δεδομένων, αλλά το περιεχόμενο των μηνυμάτων είναι βασικά το ίδιο.

Το header μπορεί να περιέχει περισσότερες γραμμές μετά την πρώτη για να πλαισιώσουν τα συμφραζόμενα και να βοηθήσουν στην αναγνώριση του αιτήματος στον server. Το πεδίο Host του header, για παράδειγμα, μπορεί να φαίνεται περιττό, επειδή ο host του server έχει προφανώς αναγνωριστεί από τον client προκειμένου να δημιουργηθεί η σύνδεση και είναι λογικό να υποθέσουμε ότι ο server γνωρίζει τη δική του ταυτότητα. Ωστόσο, είναι σημαντικό να ενημερώσετε τον host για το αναμενόμενο host όνομα στο header του αιτήματος, επειδή είναι κοινή πρακτική να χρησιμοποιείτε τον ίδιο HTTP server για να φιλοξενήσετε περισσότερους από έναν ιστότοπους. (Σε αυτό το σενάριο, κάθε συγκεκριμένος host ονομάζεται vitural host.) Επομένως, το πεδίο Host χρησιμοποιείται από τον HTTP server για να προσδιορίσει σε ποιον αναφέρεται το αίτημα.

Το πεδίο User-Agent του header περιέχει λεπτομέρειες σχετικά με το client πρόγραμμα που υποβάλλει το αίτημα. Αυτό το πεδίο μπορεί να χρησιμοποιηθεί από τον server για να προσαρμόσει την απόκριση στις ανάγκες ενός συγκεκριμένου client, αλλά χρησιμοποιείται συχνότερα για την παραγωγή στατιστικών στοιχείων σχετικά με τους clients που χρησιμοποιούν τον server.

Το πεδίο Accept έχει πιο άμεση αξία, επειδή ενημερώνει τον server σχετικά με το format του ζητούμενου πόρου. Εάν ο client αδιαφορεί για τη μορφή του πόρου, το πεδίο Accept μπορεί να καθορίσει το */* ως format.

Υπάρχουν πολλά άλλα πεδία στο header που μπορούν να χρησιμοποιηθούν σε ένα μήνυμα HTTP, αλλά τα πεδία που εμφανίζονται στο παράδειγμα είναι αρκετά για να ζητήσετε έναν πόρο από τον server.

Εκτός από τα πεδία στο header του αιτήματος, ο client μπορεί να συμπεριλάβει άλλα συμπληρωματικά δεδομένα στο HTTP αίτημα που θα σταλούν στον server. Εάν αυτά τα δεδομένα αποτελούνται μόνο από απλές παραμέτρους κειμένου, στη μορφή name=value, μπορούν να προστεθούν στο μονοπάτι της μεθόδου GET. Οι παράμετροι ενσωματώνονται στο μονοπάτι μετά από ένα ερωτηματικό και διαχωρίζονται με χαρακτήρες &:

GET /cgi-bin/receive.cgi?name=LPI&email=info@lpi.org HTTP/1.1

Σε αυτό το παράδειγμα, το /cgi-bin/receive.cgi είναι το μονοπάτι προς το script στον server που θα επεξεργαστεί και πιθανώς θα χρησιμοποιήσει τις παραμέτρους name και email, που λαμβάνονται από το μονοπάτι του αιτήματος. Το string [συμβολοσειρά] που αντιστοιχεί στα πεδία, με τη μορφή name=LPI&email=info@lpi.org, ονομάζεται query string και παρέχεται στο script receive.cgi από τον HTTP server που λαμβάνει το αίτημα.

Όταν τα δεδομένα αποτελούνται από κάτι περισσότερο από σύντομα πεδία κειμένου, είναι πιο κατάλληλο να τα στείλετε στο payload του μηνύματος. Σε αυτήν την περίπτωση, πρέπει να χρησιμοποιηθεί η μέθοδος HTTP POST, έτσι ώστε ο server να λαμβάνει και να επεξεργάζεται το payload του μηνύματος, σύμφωνα με τις προδιαγραφές που υποδεικνύονται στο header του αιτήματος. Όταν χρησιμοποιείται η μέθοδος POST, το header του αιτήματος πρέπει να παρέχει το μέγεθος του payload που θα σταλεί στη συνέχεια και τον τρόπο μορφοποίησης του σώματος:

POST /cgi-bin/receive.cgi HTTP/1.1
Host: learning.lpi.org
Content-Length: 1503
Content-Type: multipart/form-data; boundary=------------------------405f7edfd646a37d

Το πεδίο Content-Length υποδεικνύει το μέγεθος σε byte του payload και το πεδίο Content-Type υποδεικνύει τη μορφή του. Η μορφή multipart/form-data είναι αυτή που χρησιμοποιείται πιο συχνά στις παραδοσιακές φόρμες HTML που χρησιμοποιούν τη μέθοδο POST. Σε αυτήν τη μορφή, κάθε πεδίο που εισάγεται στο payload του αιτήματος διαχωρίζεται από τον κωδικό που υποδεικνύεται από τη λέξη-κλειδί boundary. Η μέθοδος POST θα πρέπει να χρησιμοποιείται μόνο όταν χρειάζεται, καθώς χρησιμοποιεί λίγο μεγαλύτερο όγκο δεδομένων από ένα ισοδύναμο αίτημα που υποβάλλεται με τη μέθοδο GET. Επειδή η μέθοδος GET στέλνει τις παραμέτρους απευθείας στο header του αιτήματος του μηνύματος, η συνολική ανταλλαγή δεδομένων έχει μικρότερο latency [καθυστέρηση μεταφοράς], επειδή δεν θα είναι απαραίτητο ένα πρόσθετο στάδιο σύνδεσης για τη μετάδοση του σώματος του μηνύματος.

Το Header Απάντησης

Αφού ο HTTP server λάβει το hader του μηνύματος αιτήματος, ο server επιστρέφει ένα μήνυμα απάντησης στον client. Ένα αίτημα αρχείου HTML έχει συνήθως ένα header απάντησης όπως αυτή:

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 18170
Content-Type: text/html
Date: Mon, 05 Apr 2021 13:44:25 GMT
Etag: "606adcd4-46fa"
Last-Modified: Mon, 05 Apr 2021 09:48:04 GMT
Server: nginx/1.17.10

Η πρώτη γραμμή παρέχει την έκδοση του HTTP πρωτοκόλλου που χρησιμοποιείται στο μήνυμα απάντησης, η οποία πρέπει να αντιστοιχεί στην έκδοση που χρησιμοποιείται στο header του αιτήματος. Στη συνέχεια, ακόμα στην πρώτη γραμμή, εμφανίζεται ο κωδικός κατάστασης της απάντησης, υποδεικνύοντας πώς ο server ερμήνευσε και δημιούργησε την απάντηση για το αίτημα.

Ο κωδικός κατάστασης είναι ένας τριψήφιος αριθμός, όπου το αριστερό ψηφίο ορίζει την κλάση απόκρισης. Υπάρχουν πέντε κατηγορίες κωδικών κατάστασης, με αρίθμηση από το 1 έως το 5, καθεμία από τις οποίες υποδεικνύει έναν τύπο ενέργειας που πραγματοποιεί ο server:

1xx (Πληροφοριακή): Το αίτημα ελήφθη, συνεχίζοντας τη διαδικασία.
2xx (Επιτυχής): Το αίτημα ελήφθη με επιτυχία, έγινε κατανοητό και αποδεκτό.
3xx (Ανακατεύθυνση): Περαιτέρω ενέργειες πρέπει να αναληφθούν προκειμένου να ολοκληρωθεί το αίτημα.
4xx (Σφάλμα Client): Το αίτημα περιέχει κακή σύνταξη ή δεν μπορεί να εκπληρωθεί.
5xx (Σφάλμα Server): Ο server απέτυχε να εκπληρώσει ένα φαινομενικά έγκυρο αίτημα.

Το δεύτερο και το τρίτο ψηφίο χρησιμοποιούνται για να υποδείξουν πρόσθετες λεπτομέρειες. Ο κωδικός 200, για παράδειγμα, υποδεικνύει ότι το αίτημα θα μπορούσε να απαντηθεί χωρίς προβλήματα. Όπως φαίνεται στο παράδειγμα, μπορεί επίσης να παρασχεθεί μια σύντομη περιγραφή κειμένου μετά τον κωδικό απόκρισης (OK). Ορισμένοι συγκεκριμένοι κωδικοί παρουσιάζουν ιδιαίτερο ενδιαφέρον για να διασφαλιστεί ότι ο HTTP client μπορεί να έχει πρόσβαση στον πόρο σε δυσμενείς καταστάσεις ή για να βοηθήσει στον εντοπισμό της αιτίας της αποτυχίας σε περίπτωση ενός αποτυχημένου αιτήματος:

301 Moved Permanently: Στον στοχευμένο πόρο έχει εκχωρηθεί μια νέα μόνιμη διεύθυνση URL, η οποία παρέχεται από το πεδίο του header Location στην απάντηση.
302 Found: Ο στοχευμένος πόρος βρίσκεται προσωρινά σε διαφορετική διεύθυνση URL.
401 Unauthorized: Το αίτημα δεν έχει εφαρμοστεί επειδή δεν διαθέτει έγκυρα διαπιστευτήρια ελέγχου ταυτότητας για τον πόρο στόχο.
403 Forbidden: Η απάντηση Forbidden υποδεικνύει ότι, αν και το αίτημα είναι έγκυρο, ο server έχει ρυθμιστεί έτσι ώστε να μην το παρέχει.
404 Not Found: Ο server προέλευσης δεν βρήκε κάποια τρέχουσα αναπαράσταση για τον πόρο στόχο ή δεν είναι πρόθυμος να αποκαλύψει ότι υπάρχει.
500 Internal Server Error: Ο server αντιμετώπισε μια απροσδόκητη συνθήκη που τον εμπόδισε να εκπληρώσει το αίτημα.
502 Bad Gateway: Ο server, ενώ ενεργούσε ως gateway ή proxy, έλαβε μια μη έγκυρη απάντηση από έναν εισερχόμενο server στον οποίο είχε πρόσβαση ενώ προσπαθούσε να εκπληρώσει το αίτημα.

Παρόλο που υποδεικνύουν ότι δεν ήταν δυνατή η εκπλήρωση του αιτήματος, οι κωδικοί κατάστασης 4xx και 5xx τουλάχιστον υποδεικνύουν ότι ο HTTP server τρέχει και μπορεί να λαμβάνει αιτήματα. Οι κωδικοί 4xx απαιτούν να γίνει μια ενέργεια στον client, επειδή η διεύθυνση URL ή τα διαπιστευτήριά του είναι λανθασμένα. Αντίθετα, οι κωδικοί 5xx υποδεικνύουν ότι κάτι δεν πάει καλά στην πλευρά του server. Επομένως, στο πλαίσιο των web εφαρμογών, αυτές οι δύο κατηγορίες κωδικών κατάστασης υποδεικνύουν ότι η πηγή του σφάλματος βρίσκεται στην ίδια την εφαρμογή, είτε στον client είτε στον server, και όχι στην υποκείμενη υποδομή.

Στατικό και Δυναμικό Περιεχόμενο

Οι HTTP servers χρησιμοποιούν δύο βασικούς μηχανισμούς για να εκπληρώσουν το περιεχόμενο που ζητά ο client. Ο πρώτος μηχανισμός παρέχει στατικό περιεχόμενο: δηλαδή, το μονοπάτι που υποδεικνύεται στο μήνυμα του αιτήματος αντιστοιχεί σε ένα αρχείο στο τοπικό σύστημα αρχείων του server. Ο δεύτερος μηχανισμός παρέχει δυναμικό περιεχόμενο: δηλαδή, ο HTTP server προωθεί το αίτημα σε άλλο πρόγραμμα—πιθανότατα ένα script‒για τη δημιουργία της απάντησης από διαφορετικές πηγές, όπως βάσεις δεδομένων και άλλα αρχεία.

Αν και υπάρχουν διαφορετικοί HTTP servers, όλοι χρησιμοποιούν το ίδιο πρωτόκολλο επικοινωνίας HTTP και υιοθετούν λίγο πολύ τις ίδιες συμβάσεις. Μια εφαρμογή που δεν έχει συγκεκριμένη ανάγκη μπορεί να υλοποιηθεί με οποιονδήποτε παραδοσιακό server, όπως Apache ή NGINX. Και οι δύο είναι ικανοί να δημιουργούν δυναμικό περιεχόμενο και να παρέχουν στατικό περιεχόμενο, αλλά υπάρχουν λεπτές διαφορές στη διαμόρφωση του καθενός.

Η θέση των στατικών αρχείων προς εξυπηρέτηση, για παράδειγμα, ορίζεται με διαφορετικούς τρόπους στον Apache και τον NGINX. Η σύμβαση είναι να διατηρούνται αυτά τα αρχεία σε έναν συγκεκριμένο κατάλογο για το σκοπό αυτό, έχοντας ένα όνομα που σχετίζεται με τον host, για παράδειγμα /var/www/learning.lpi.org/. Στον Apache, αυτό το μονοπάτι ορίζεται από την οδηγία διαμόρφωσης DocumentRoot /var/www/learning.lpi.org, σε μια ενότητα που ορίζει έναν virtual host. Στον NGINX, η οδηγία που χρησιμοποιείται είναι root /var/www/learning.lpi.org σε μια ενότητα server του αρχείου διαμόρφωσης.

Όποιον server και αν επιλέξετε, τα αρχεία στο /var/www/learning.lpi.org/ θα εξυπηρετούνται μέσω HTTP με σχεδόν τον ίδιο τρόπο. Ορισμένα πεδία στο header της απάντησης και το περιεχόμενό τους ενδέχεται να διαφέρουν μεταξύ των δύο servers, αλλά πεδία όπως το Content-Type πρέπει να υπάρχουν στο header της απάντησης και να είναι συνεπή σε οποιονδήποτε server.

Caching

Το HTTP σχεδιάστηκε για να λειτουργεί σε οποιονδήποτε τύπο σύνδεσης στο Διαδίκτυο, γρήγορο ή αργό. Επιπλέον, οι περισσότερες ανταλλαγές HTTP πρέπει να διασχίσουν πολλούς κόμβους δικτύου λόγω της κατανεμημένης αρχιτεκτονικής του Διαδικτύου. Ως αποτέλεσμα, είναι σημαντικό να υιοθετήσετε κάποια στρατηγική caching [προσωρινή αποθήκευση/μνήμη] περιεχομένου για να αποφύγετε την περιττή μεταφορά περιεχομένου που έχετε λάβει προηγουμένως. Οι μεταφορές HTTP μπορούν να λειτουργήσουν με δύο βασικούς τύπους cache: shared και private.

Ένα shared cache χρησιμοποιείται από περισσότερους από έναν client. Για παράδειγμα, ένας μεγάλος πάροχος περιεχομένου μπορεί να χρησιμοποιεί caches σε γεωγραφικά κατανεμημένους servers, έτσι ώστε οι clients να λαμβάνουν τα δεδομένα από τον πλησιέστερο server τους. Μόλις ένας client υποβάλει ένα αίτημα και η απάντησή του αποθηκευτεί σε ένα shared cache, άλλοι clients που υποβάλλουν το ίδιο αίτημα στην ίδια γεωγραφική περιοχή θα λάβουν την αποθηκευμένη απάντηση.

Ένα private cache δημιουργείται από τον ίδιο τον client για αποκλειστική χρήση. Είναι ο τύπος του caching που κάνει το πρόγραμμα περιήγησης web για εικόνες, αρχεία CSS, JavaScript ή το ίδιο το HTML έγγραφο, επομένως δεν χρειάζεται να ληφθούν ξανά, εάν ζητηθούν ξανά στο εγγύς μέλλον.

Note

Δεν πρέπει να γίνονται cached όλα τα αιτήματα HTTP. Ένα αίτημα που χρησιμοποιεί τη μέθοδο POST, για παράδειγμα, συνεπάγεται μια απάντηση που σχετίζεται αποκλειστικά με το συγκεκριμένο αίτημα, επομένως το περιεχόμενο της απάντησής του δεν πρέπει να επαναχρησιμοποιηθεί. Από προεπιλογή, γίνονται cached μόνο οι απαντήσεις σε αιτήματα που γίνονται με τη μέθοδο GET. Επιπλέον, μόνο απαντήσεις με οριστικούς κωδικούς κατάστασης όπως 200 (OK), 206 (Partial Content), 301 (Moved Permanently) και 404 (Not Found) είναι κατάλληλες για caching.

Τόσο η στρατηγική του shared όσο και του private cache χρησιμοποιούν HTTP headers για τον έλεγχο του τρόπου με τον οποίο πρέπει να γίνει cached το περιεχόμενο που έχει ληφθεί. Για το private cache, ο client συμβουλεύεται το header της απάντησης και επαληθεύει εάν το περιεχόμενο στο τοπικό cache εξακολουθεί να αντιστοιχεί στο τρέχον απομακρυσμένο περιεχόμενο. Εάν συμβαίνει αυτό, ο client παραιτείται από τη μεταφορά του payload της απάντησης και χρησιμοποιεί το τοπικό περιεχόμενο.

Η εγκυρότητα του cached πόρου μπορεί να εκτιμηθεί με διάφορους τρόπους. Ο server μπορεί να παρέχει μια ημερομηνία λήξης στο header της απάντησης για το πρώτο αίτημα, έτσι ώστε ο client να απορρίψει τον cached πόρο στο τέλος της περιόδου και να τον ζητήσει ξανά για να αποκτήσει την ενημερωμένη έκδοση. Ωστόσο, ο server δεν είναι πάντα σε θέση να προσδιορίσει την ημερομηνία λήξης ενός πόρου, επομένως είναι σύνηθες να χρησιμοποιείται το πεδίο ETag στο header της απάντησης για να προσδιορίσει την έκδοση του πόρου, για παράδειγμα Etag: "606adcd4-46fa".

Για να επαληθευτεί ότι ένας cached πόρος χρειάζεται ενημέρωση, ο client ζητά μόνο το header της απάντησής του από τον server. Εάν το πεδίο ETag ταιριάζει με αυτό στην τοπικά αποθηκευμένη έκδοση, ο client επαναχρησιμοποιεί το cached περιεχόμενο. Διαφορετικά, γίνεται λήψη του ενημερωμένου περιεχομένου του πόρου από τον server.

HTTP Sessions

Σε έναν συμβατικό ιστότοπο ή μια web εφαρμογή, οι λειτουργίες που χειρίζονται τον έλεγχο ενός session [συνεδρία] βασίζονται σε HTTP headers. Ο server δεν μπορεί να υποθέσει, για παράδειγμα, ότι όλα τα αιτήματα που προέρχονται από την ίδια διεύθυνση IP προέρχονται από τον ίδιο client. Η πιο παραδοσιακή μέθοδος που επιτρέπει στον server να συσχετίζει διαφορετικά αιτήματα σε έναν μόνο client είναι η χρήση των cookies [μπισκότα], μιας ετικέτας αναγνώρισης που δίνεται στον client από τον server και παρέχεται στο HTTP header.

Τα cookies επιτρέπουν στον server να διατηρεί πληροφορίες σχετικά με έναν συγκεκριμένο client, ακόμα κι αν το άτομο που διευθύνει τον client δεν προσδιορίζει ρητά τον εαυτό του. Με τα cookies, είναι δυνατή η υλοποίηση sessions όπου στοιχεία σύνδεσης, καλάθια αγορών, προτιμήσεις κ.λπ., διατηρούνται μεταξύ διαφορετικών αιτημάτων που γίνονται στον ίδιο τον server που τα παρείχε. Τα cookies χρησιμοποιούνται επίσης για την παρακολούθηση της περιήγησης των χρηστών, επομένως είναι σημαντικό να ζητηθεί η συγκατάθεσή τους πριν από την αποστολή τους.

Ο server ορίζει το cookie στο header της απάντησης χρησιμοποιώντας το πεδίο Set-Cookie. Η τιμή πεδίου είναι ένα ζεύγος name=value που επιλέχθηκε για να αντιπροσωπεύει κάποιο χαρακτηριστικό που σχετίζεται με έναν συγκεκριμένο client. Ο server μπορεί, για παράδειγμα, να δημιουργήσει έναν αριθμό αναγνώρισης για έναν client που ζητά έναν πόρο για πρώτη φορά και να τον περάσει στον client στο header της απάντησης:

HTTP/1.1 200 OK
Accept-Ranges: bytes
Set-Cookie: client_id=62b5b719-fcbf

Εάν ο client επιτρέπει τη χρήση cookies, τα νέα αιτήματα στον ίδιο server έχουν το πεδίο cookie στο header:

GET /en/ HTTP/1.1
Host: learning.lpi.org
Cookie: client_id=62b5b719-fcbf

Με αυτόν τον αριθμό αναγνώρισης, ο server μπορεί να ανακτήσει συγκεκριμένους ορισμούς για τον client και να δημιουργήσει μια προσαρμοσμένη απάντηση. Είναι επίσης δυνατό να χρησιμοποιηθούν περισσότερα από ένα πεδία Set-Cookie για την παράδοση διαφορετικών cookies στον ίδιο πελάτη. Με αυτόν τον τρόπο, μπορούν να διατηρηθούν περισσότεροι από ένας ορισμοί στην πλευρά του client.

Τα cookies εγείρουν τόσο ζητήματα απορρήτου όσο και πιθανά κενά ασφαλείας, επειδή υπάρχει πιθανότητα να μεταφερθούν σε άλλο client, ο οποίος θα αναγνωριστεί από τον server ως ο αρχικός client. Τα cookies που χρησιμοποιούνται για τη διατήρηση των sessions μπορούν να παρέχουν πρόσβαση σε ευαίσθητες πληροφορίες από τον αρχικό client. Επομένως, είναι πολύ σημαντικό για τους clients να υιοθετήσουν τοπικούς μηχανισμούς προστασίας για να αποτρέψουν την εξαγωγή και επαναχρησιμοποίηση των cookie τους χωρίς εξουσιοδότηση.

Καθοδηγούμενες Ασκήσεις

Ποια μέθοδο HTTP χρησιμοποιεί το ακόλουθο μήνυμα αιτήματος;

POST /cgi-bin/receive.cgi HTTP/1.1
Host: learning.lpi.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0
Accept: */*
Content-Length: 27
Content-Type: application/x-www-form-urlencoded

Όταν ένας HTTP server φιλοξενεί πολλούς ιστότοπους, πώς μπορεί να προσδιορίσει σε ποιον απευθύνεται ένα αίτημα;
Ποια παράμετρος παρέχεται από το query string της διεύθυνσης URL https://www.google.com/search?q=LPI;

Γιατί το ακόλουθο αίτημα HTTP δεν είναι κατάλληλο για caching;

POST /cgi-bin/receive.cgi HTTP/1.1
Host: learning.lpi.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0
Accept: */*
Content-Length: 27
Content-Type: application/x-www-form-urlencoded

Ασκήσεις Εξερεύνησης

Πώς θα μπορούσατε να χρησιμοποιήσετε το πρόγραμμα περιήγησης για να παρακολουθείτε τα αιτήματα και τις απαντήσεις που γίνονται από μια σελίδα HTML;
Οι HTTP servers που παρέχουν στατικό περιεχόμενο συνήθως αντιστοιχίζουν το αιτούμενο μονοπάτι σε ένα αρχείο στο σύστημα αρχείων του server. Τι συμβαίνει όταν το μονοπάτι στο αίτημα δείχνει σε έναν κατάλογο;
Τα περιεχόμενα των αρχείων που αποστέλλονται μέσω HTTPS προστατεύονται με κρυπτογράφηση, επομένως δεν μπορούν να διαβαστούν από υπολογιστές μεταξύ του client και του server. Παρόλα αυτά, μπορούν αυτοί οι υπολογιστές στη μέση να προσδιορίσουν τον πόρο που έχει ζητήσει ο client από τον server;

Σύνοψη

Αυτό το μάθημα καλύπτει τα βασικά του HTTP, του κύριου πρωτοκόλλου που χρησιμοποιείται από client εφαρμογές για να ζητούν πόρους από web servers. Το μάθημα περιλαμβάνει τις ακόλουθες έννοιες:

Μηνύματα αιτήματος, πεδία header, και μέθοδοι.
Κωδικοί κατάστασης απάντησης.
Πώς οι HTTP servers δημιουργούν απαντήσεις.
Λειτουργίες HTTP χρήσιμες για caching και διαχείριση session.

Απαντήσεις στις Καθοδηγούμενες Ασκήσεις

Ποια μέθοδο HTTP χρησιμοποιεί το ακόλουθο μήνυμα αιτήματος;

POST /cgi-bin/receive.cgi HTTP/1.1
Host: learning.lpi.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0
Accept: */*
Content-Length: 27
Content-Type: application/x-www-form-urlencoded

Την μέθοδο POST.

Όταν ένας HTTP server φιλοξενεί πολλούς ιστότοπους, πώς μπορεί να προσδιορίσει σε ποιον απευθύνεται ένα αίτημα;

Το πεδίο Host στο header του αιτήματος παρέχει τον στοχευμένο ιστότοπο.
Ποια παράμετρος παρέχεται από το query string της διεύθυνσης URL https://www.google.com/search?q=LPI;

Η παράμετρος με το όνομα q με τιμή LPI.
Γιατί το ακόλουθο αίτημα HTTP δεν είναι κατάλληλο για caching;
```
POST /cgi-bin/receive.cgi HTTP/1.1
Host: learning.lpi.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0
Accept: */*
Content-Length: 27
Content-Type: application/x-www-form-urlencoded
```
Επειδή τα αιτήματα που γίνονται με τη μέθοδο POST συνεπάγονται μια λειτουργία εγγραφής στον server, δεν πρέπει να γίνονται cached.

Απαντήσεις στις Ασκήσεις Εξερεύνησης

Πώς θα μπορούσατε να χρησιμοποιήσετε το πρόγραμμα περιήγησης για να παρακολουθείτε τα αιτήματα και τις απαντήσεις που γίνονται από μια σελίδα HTML;

Όλα τα δημοφιλή προγράμματα περιήγησης προσφέρουν development tools που, μεταξύ άλλων, μπορούν να εμφανίσουν όλες τις δικτυακές συναλλαγές που έχουν πραγματοποιηθεί από την τρέχουσα σελίδα.
Οι HTTP servers που παρέχουν στατικό περιεχόμενο συνήθως αντιστοιχίζουν το αιτούμενο μονοπάτι σε ένα αρχείο στο σύστημα αρχείων του server. Τι συμβαίνει όταν το μονοπάτι στο αίτημα δείχνει σε έναν κατάλογο;

Εξαρτάται από το πώς έχει ρυθμιστεί ο server. Από προεπιλογή, οι περισσότεροι HTTP server αναζητούν ένα αρχείο με το όνομα index.html (ή άλλο προκαθορισμένο όνομα) στον ίδιο κατάλογο και το στέλνουν ως απάντηση. Εάν το αρχείο δεν υπάρχει, ο server εκδίδει μια απάντηση 404 Not Found.
Τα περιεχόμενα των αρχείων που αποστέλλονται μέσω HTTPS προστατεύονται με κρυπτογράφηση, επομένως δεν μπορούν να διαβαστούν από υπολογιστές μεταξύ του client και του server. Παρόλα αυτά, μπορούν αυτοί οι υπολογιστές στη μέση να προσδιορίσουν τον πόρο που έχει ζητήσει ο client από τον server;

Όχι, επειδή τα ίδια τα HTTP headers των αιτημάτων και των απαντήσεων είναι επίσης κρυπτογραφημένα από το TLS.