Το όνομα κεντρικού υπολογιστή του μπροστινού διαμεσολαβητή λείπει από το αίτημα

Ένα απλό αίτημα HTTP μέσω μπροστινού διαμεσολαβητή προσδιορίζει τον προορισμό, επομένως το Host και το hostname του Express δεν μπορούν να διακρίνουν ψευδώνυμα του ίδιου του διαμεσολαβητή.

Ας υποθέσουμε ότι τα east.proxy.example και west.proxy.example αναλύονται στον ίδιο απλό ακροατή HTTP του διαμεσολαβητή. Ένας πελάτης που χρησιμοποιεί οποιοδήποτε από τα δύο ονόματα μπορεί να στείλει:

GET http://www.example.org/report HTTP/1.1
Host: www.example.org

Το αίτημα προσδιορίζει τον ιστότοπο. Δεν μεταφέρει το ψευδώνυμο του διαμεσολαβητή που ανέλυσε ο πελάτης πριν ανοίξει το TCP. Επομένως το hostname του Express που προκύπτει από το Host δεν μπορεί να επιλέξει διαδρομή με βάση αυτούς τους υποτομείς του διαμεσολαβητή.

Αν ελέγχετε τον πελάτη και τον διαμεσολαβητή, δώστε μια ρητή είσοδο δρομολόγησης. Για διαμεσολαβητή που υλοποιεί ετικέτα X-Route:

curl --proxy http://east.proxy.example:8080 \
  --proxy-header 'X-Route: east' \
  https://www.example.org/

Το --proxy-header στοχεύει την επικοινωνία με τον διαμεσολαβητή, συμπεριλαμβανομένου του CONNECT. Μια συνηθισμένη κεφαλίδα -H στο αίτημα HTTPS ανήκει μέσα στην κρυπτογραφημένη ανταλλαγή HTTP του προορισμού.

Ο διακομιστής πρέπει να υλοποιεί και να εξουσιοδοτεί την πολιτική δρομολόγησης και έπειτα να καταναλώνει την ετικέτα χωρίς να την προωθεί στον ιστότοπο. Εναλλακτικά, χρησιμοποιήστε ξεχωριστά ρυθμισμένα τελικά σημεία ακρόασης ή λογαριασμούς διαμεσολαβητή ως εισόδους δρομολόγησης.

Για προορισμούς HTTPS, το Node λαμβάνει το αρχικό αίτημα σήραγγας μέσω του συμβάντος connect του διακομιστή HTTP του. Το συνηθισμένο middleware αιτημάτων του Express δεν χειρίζεται αυτό το συμβάν. Ο στόχος CONNECT εξακολουθεί να προσδιορίζει τον διακομιστή προορισμού, όχι το ψευδώνυμο του διαμεσολαβητή.

Σχετικά άρθρα