Merutekan Permintaan Masuk

  • Artikel

HTTP Server API mempertahankan database perutean untuk menentukan aplikasi mana yang menerima permintaan masuk. Tabel perutean dibangun dari database reservasi dan berisi entri reservasi serta pendaftaran saat ini. Ketika pendaftaran atau reservasi dilakukan, pendaftaran atau reservasi ditempatkan ke dalam wadah database perutean yang sesuai dengan jenis host sebagai berikut:

  • + : pendaftaran port ditempatkan di wadah "Wildcard Kuat"

  • host : pendaftaran port ditempatkan di wadah "Eksplisit"

  • IP : pendaftaran port ditempatkan di wadah "Wildcard Lemah yang terikat IP"

  • * : pendaftaran port ditempatkan di wadah "Wildcard Lemah"

Langkah-langkah ini juga merujuk pada permintaan HTTP masuk pesanan diproses. Reservasi wildcard yang kuat terlebih dahulu, kemudian reservasi eksplisit diperiksa diikuti oleh wildcard lemah yang terikat IP dan wildcard yang lemah. Pencarian berhenti ketika kecocokan ditemukan sehingga pendaftaran di salah satu wadah yang tersisa tidak ditemukan.

Algoritma perutean HTTP Server API menemukan kecocokan terbaik untuk UrlPrefix dengan mencari entri pendaftaran dan entri reservasi database perutean, dimulai dengan wadah wildcard yang kuat dan diakhiri dengan wadah wildcard yang lemah. Kecocokan terbaik, dalam wadah, adalah kecocokan terpanjang dalam bagian URI relatif dari UrlPrefix (dengan asumsi kecocokan yang tepat untuk bagian host, port, dan skema URL). Setelah kecocokan ditemukan dalam wadah, algoritma perutean menghentikan pencariannya dan melewati semua wadah prioritas yang lebih rendah.

Misalnya, pertimbangkan pendaftaran berikut (tercantum dalam urutan prioritas turun berdasarkan jenis wadah:

  • Pendaftaran: https://+:80/vroot/ didaftarkan oleh aplikasi 1

  • Pendaftaran: https://adatum.com:80/ didaftarkan oleh aplikasi 2

  • Pendaftaran: https://\*:80/ didaftarkan oleh aplikasi 3

Permintaan masuk untuk https://adatum.com:80/vroot/subdir/file.htm/ dikirimkan ke aplikasi 1. Permintaan masuk untuk https://adatum.com:80/default.htm/ dikirimkan ke aplikasi 2. Permintaan masuk untuk https://otheradatum.com:80/file.htm/ dikirimkan ke aplikasi 3.

Jika kecocokan terbaik adalah entri reservasi, ini berarti bahwa aplikasi yang seharusnya menerima permintaan tidak berjalan. Misalnya, pertimbangkan pendaftaran dan reservasi berikut:

  • Pendaftaran: https://\*:80/vroot/ didaftarkan oleh aplikasi 1, pengguna A

  • Reservasi: https://adatum.com:80/ telah dicadangkan untuk pengguna B

Permintaan masuk untuk https://adatum.com:80/vroot/file.htm/ tidak dikirimkan ke aplikasi 1 karena kecocokan terbaik mengarah ke entri reservasi untuk pengguna B. Aturan prioritas diterapkan dalam hal ini ke reservasi yang memiliki prioritas lebih tinggi. Jika tidak ada proses aktif yang diotorisasi dan didaftarkan ke permintaan layanan untuk URL yang diterima, permintaan ditolak dengan kode status 400 (Permintaan Buruk).