Το HTTP ορίζει διαφορετικούς τρόπους αλληλεπίδρασης με τον διακομιστή και υπάρχουν 4 βασικές μέθοδοι, δηλαδή GET, POST, PUT και DELETE. Το πλήρες όνομα της διεύθυνσης URL είναι ένας περιγραφέας πόρων, μπορούμε να το σκεφτούμε ως εξής: μια διεύθυνση URL, χρησιμοποιείται για να περιγράψει έναν πόρο σε ένα δίκτυο και το GET, POST, PUT, DELETE στο HTTP αντιστοιχεί στις τέσσερις λειτουργίες ελέγχου, τροποποίησης, προσθήκης και διαγραφής αυτού του πόρου. Σε αυτό το σημείο, θα πρέπει να έχετε μια γενική κατανόηση, το GET χρησιμοποιείται γενικά για τη λήψη/αναζήτηση πληροφοριών πόρων, ενώ το POST χρησιμοποιείται γενικά για την ενημέρωση πληροφοριών πόρων.
1. Σύμφωνα με την προδιαγραφή HTTP, το GET χρησιμοποιείται για την ανάκτηση πληροφοριών και θα πρέπει να είναι ασφαλές και ανίσχυρο.
(1). Η λεγόμενη ασφάλεια σημαίνει ότι η λειτουργία χρησιμοποιείται για τη λήψη πληροφοριών και όχι για την τροποποίησή τους. Με άλλα λόγια, τα αιτήματα GET γενικά δεν πρέπει να έχουν παρενέργειες. Δηλαδή, λαμβάνει μόνο πληροφορίες πόρων, όπως και το ερώτημα βάσης δεδομένων, και δεν θα τροποποιήσει, δεν θα προσθέσει δεδομένα ή δεν θα επηρεάσει την κατάσταση του πόρου.
* Σημείωση: Η έννοια της ασφάλειας εδώ αναφέρεται μόνο σε μη τροποποιημένες πληροφορίες.
(2). idempotent σημαίνει ότι πολλαπλές αιτήσεις στην ίδια διεύθυνση URL θα πρέπει να επιστρέφουν το ίδιο αποτέλεσμα.
Ωστόσο, στην πρακτική εφαρμογή, οι δύο παραπάνω κανονισμοί δεν είναι τόσο αυστηροί. Παραδείγματα παράθεσης άρθρων άλλων ανθρώπων: Για παράδειγμα, η πρώτη σελίδα ενός ειδησεογραφικού ιστότοπου ενημερώνεται συνεχώς. Ενώ το δεύτερο αίτημα επιστρέφει μια διαφορετική παρτίδα ειδήσεων, η λειτουργία εξακολουθεί να θεωρείται ασφαλής και ανίκανη επειδή επιστρέφει πάντα τις τρέχουσες ειδήσεις. Βασικά, εάν ο στόχος είναι ότι όταν ένας χρήστης ανοίγει έναν σύνδεσμο, μπορεί να είναι σίγουρος ότι ο πόρος δεν έχει αλλάξει από την άποψή του.
2. Σύμφωνα με την προδιαγραφή HTTP, το POST αντιπροσωπεύει ένα αίτημα που μπορεί να τροποποιήσει έναν πόρο στον διακομιστή. Συνεχίζοντας να παραθέτω το παραπάνω παράδειγμα: Still news Πάρτε για παράδειγμα τον ιστότοπο, οι αναγνώστες θα πρέπει να δημοσιεύουν τα δικά τους σχόλια στις ειδήσεις, επειδή οι πόροι του ιστότοπου είναι διαφορετικοί μετά την υποβολή του σχολίου ή την τροποποίηση των πόρων.
Τα παραπάνω συζητούν χονδρικά μερικές από τις αρχές του GET και του POST στην προδιαγραφή HTTP. Ωστόσο, πολλοί άνθρωποι δεν ακολουθούν την προδιαγραφή HTTP όταν το κάνουν πραγματικά, γεγονός που μπορεί να οδηγήσει σε πολλούς λόγους για αυτό το πρόβλημα, όπως:
1. Πολλοί άνθρωποι χρησιμοποιούν το GET για να ενημερώσουν τους πόρους επειδή πρέπει να μεταβούν στο FORM για να χρησιμοποιήσουν το POST, κάτι που θα είναι λίγο ενοχλητικό.
2. Η λειτουργία προσθήκης, διαγραφής, τροποποίησης και ελέγχου πόρων μπορεί πραγματικά να ολοκληρωθεί μέσω GET/POST, χωρίς να χρειάζεται να χρησιμοποιήσετε PUT και DELETE.
3. Ένα άλλο είναι ότι οι πρώτοι σχεδιαστές πλαισίων Web MVC δεν αντιμετώπιζαν και δεν σχεδίαζαν συνειδητά τις διευθύνσεις URL ως αφηρημένους πόρους, επομένως ένα σοβαρό πρόβλημα είναι ότι το παραδοσιακό πλαίσιο Web MVC υποστηρίζει βασικά μόνο δύο μεθόδους HTTP, GET και POST, αλλά δεν υποστηρίζει μεθόδους PUT και DELETE.
* Μια σύντομη εξήγηση του MVC: Το MVC υπήρχε αρχικά στο πρόγραμμα Desktop, το M αναφέρεται στο μοντέλο δεδομένων, το V αναφέρεται στη διεπαφή χρήστη και το C αναφέρεται στον ελεγκτή. Ο σκοπός της χρήσης του MVC είναι να διαχωριστεί ο κώδικας υλοποίησης των M και V, έτσι ώστε το ίδιο πρόγραμμα να μπορεί να χρησιμοποιεί διαφορετικές αναπαραστάσεις.
Τα παραπάνω 3 σημεία περιγράφουν τυπικά το παλιό στυλ (χωρίς αυστηρή τήρηση της προδιαγραφής HTTP), με την ανάπτυξη της αρχιτεκτονικής, τώρα υπάρχει το REST (Representational State Transfer), ένα νέο στυλ που υποστηρίζει την προδιαγραφή HTTP.
Αφού μιλήσουμε για το βασικό πρόβλημα, ας δούμε τη διαφορά μεταξύ GET και POST από το φαινόμενο της επιφάνειας:
1. Τα δεδομένα του αιτήματος GET θα επισυναφθούν στη διεύθυνση URL (δηλαδή, τα δεδομένα τοποθετούνται στην κεφαλίδα του πρωτοκόλλου HTTP) και το ? Διαχωρίστε τη διεύθυνση URL και μεταδώστε τα δεδομένα και οι παράμετροι συνδέονται με &, για παράδειγμα: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD. Εάν τα δεδομένα είναι αγγλικά γράμματα/αριθμοί, στείλτε τα ως έχουν, εάν είναι κενό, μετατρέψτε τα σε +, εάν είναι κινεζικοί/άλλοι χαρακτήρες και, στη συνέχεια, κρυπτογραφήστε απευθείας τη συμβολοσειρά με BASE64 για να λάβετε ένα δείγμα όπως: %E4%BD%A0%E5%A5%BD, όπου XX στο %XX είναι το ASCII που αντιπροσωπεύεται από το σύμβολο σε δεκαεξαδικό.
Το POST τοποθετεί τα υποβληθέντα δεδομένα στο σώμα του πακέτου HTTP.
2. "Τα μέγιστα δεδομένα που υποβάλλονται με τη μέθοδο GET μπορούν να είναι μόνο 1024 byte, θεωρητικά δεν υπάρχει όριο στο POST και μπορεί να μεταφερθεί μεγάλος όγκος δεδομένων, έως 80 KB στο IIS4 και 100 KB στο IIS5"??!
Η παραπάνω πρόταση ανακατευθύνεται από άλλα άρθρα, στην πραγματικότητα, είναι λάθος και ανακριβές να λέμε αυτό:
(1). Πρώτα απ 'όλα, "τα δεδομένα που υποβάλλονται με τη μέθοδο GET μπορούν να είναι μόνο 1024 byte το πολύ", επειδή η GET υποβάλλει δεδομένα μέσω URL, επομένως ο όγκος των δεδομένων που μπορούν να υποβληθούν από τη GET σχετίζεται άμεσα με το μήκος της διεύθυνσης URL. Στην πραγματικότητα, δεν υπάρχει ανώτατο όριο παραμέτρων για τις διευθύνσεις URL και η προδιαγραφή πρωτοκόλλου HTTP δεν περιορίζει το μήκος των διευθύνσεων URL. Αυτό το όριο είναι ένας περιορισμός που επιβάλλεται από ένα συγκεκριμένο πρόγραμμα περιήγησης και διακομιστή. Το όριο του IE στο μήκος URL είναι 2083 byte (2K+35). Για άλλα προγράμματα περιήγησης όπως το Netscape, το FireFox κ.λπ., δεν υπάρχει θεωρητικό όριο μήκους και το όριο του εξαρτάται από την υποστήριξη του λειτουργικού συστήματος.
Λάβετε υπόψη ότι αυτό περιορίζει ολόκληρο το μήκος του URL και όχι μόνο το μήκος δεδομένων της τιμής της παραμέτρου. [Βλ. Αναφορά 5]
(2). Θεωρητικά, το POST δεν έχει όριο μεγέθους και η προδιαγραφή πρωτοκόλλου HTTP δεν έχει όριο μεγέθους και είναι ανακριβές να πούμε ότι "υπάρχει όριο μεγέθους 80K/100K για δεδομένα POST" και δεν υπάρχει όριο στα δεδομένα POST και είναι η επεξεργαστική ισχύς του χειριστή του διακομιστή που παίζει περιοριστικό ρόλο.
Για προγράμματα ASP, το αντικείμενο αίτησης έχει όριο μήκους δεδομένων 100K κατά την επεξεργασία κάθε πεδίου φόρμας. Αλλά με το Request.BinaryRead δεν υπάρχει τέτοιος περιορισμός.
Μετά από αυτό, για τις υπηρεσίες IIS 6.0, η Microsoft αύξησε τους περιορισμούς για λόγους ασφαλείας. Πρέπει επίσης να προσέξουμε:
1). Οι υπηρεσίες IIS 6.0 έχουν από προεπιλογή έως 200 KB δεδομένων ASP POST και το όριο είναι 100 KB ανά πεδίο φόρμας.
2). Το προεπιλεγμένο μέγεθος των αρχείων αποστολής IIS 6.0 είναι 4 MB.
3). Οι υπηρεσίες IIS 6.0 έχουν από προεπιλογή μια μέγιστη κεφαλίδα αίτησης 16 KB.
Αυτοί οι περιορισμοί δεν ήταν διαθέσιμοι πριν από το IIS 6.0. [Βλ. Αναφορά 5]
Επομένως, τα παραπάνω 80K και 100K μπορεί να είναι απλώς οι προεπιλεγμένες τιμές (σημείωση: Δεν έχω επιβεβαιώσει ακόμα τις παραμέτρους των IIS4 και IIS5), αλλά σίγουρα μπορείτε να τις ορίσετε μόνοι σας. Επειδή οι προεπιλεγμένες τιμές για αυτές τις παραμέτρους είναι διαφορετικές σε κάθε έκδοση των υπηρεσιών IIS, ανατρέξτε στο σχετικό έγγραφο ρύθμισης παραμέτρων των υπηρεσιών IIS για λεπτομέρειες.
3. Στο ASP, ο διακομιστής χρησιμοποιεί το Request.QueryString για να λάβει την παράμετρο αιτήματος GET και το Request.Form για να λάβει την παράμετρο αιτήματος POST. Στο JSP, χρησιμοποιήστε το request.getParameter(\"XXXX\") για να το λάβετε, αν και υπάρχει επίσης μια μέθοδος request.getQueryString() στο jsp, αλλά είναι πιο ενοχλητικό να το χρησιμοποιήσετε, για παράδειγμα: στείλτε ένα test.jsp?name=hyddd&password=hyddd και χρησιμοποιήστε το request.getQueryString() για να λάβετε :name= hyddd&password=hyddd。 Στην PHP, μπορείτε να χρησιμοποιήσετε $_GET και $_POST για να λάβετε δεδομένα από το GET και το POST αντίστοιχα, ενώ το $_REQUEST μπορεί να λάβει δεδομένα τόσο από αιτήματα GET όσο και από POST. Αξίζει να σημειωθεί ότι υπάρχουν κρυφοί κίνδυνοι στη χρήση αιτήματος στο JSP και $_REQUEST στην PHP, οι οποίοι θα συνοψιστούν σε ένα άρθρο την επόμενη φορά.
4.POST είναι πιο ασφαλές από το GET. Σημείωση: Η ασφάλεια που αναφέρεται εδώ δεν είναι η ίδια έννοια με την «ασφάλεια» που αναφέρεται στο GET παραπάνω. Για παράδειγμα, εάν υποβάλετε δεδομένα μέσω του GET, το όνομα χρήστη και ο κωδικός πρόσβασής σας θα εμφανίζονται σε απλό κείμενο στη διεύθυνση URL, επειδή (1) η σελίδα σύνδεσης μπορεί να αποθηκευτεί προσωρινά από το πρόγραμμα περιήγησης, (2) άλλοι θα δουν το ιστορικό του προγράμματος περιήγησης, ώστε οι άλλοι να μπορούν να λάβουν τον λογαριασμό και τον κωδικό πρόσβασής σας επίθεση πλαστογραφίας.
Συνοψίζοντας, το Get είναι ένα αίτημα για αίτημα δεδομένων από τον διακομιστή, ενώ το Post είναι ένα αίτημα για υποβολή δεδομένων στον διακομιστή, στο FORM, η μέθοδος προεπιλογή είναι "GET", στην ουσία, το GET και το POST είναι απλώς διαφορετικοί μηχανισμοί αποστολής, δεν παίρνει και στέλνει ένα!
|
Δημοσιεύτηκε στις 6/12/2014 10:54:55 π.μ.
|
|
|
Δημοσιεύτηκε στις 7/12/2014 5:24:18 μ.μ.
