Bagikan melalui

String UrlPrefix

  • Artikel

Dalam HTTP Server API, UrlPrefix adalah string Unicode karakter lebar (UTF-16) dengan bentuk kanonis yang menentukan bagian namespace URL. Ini digunakan untuk memesan bagian namespace URL untuk akun pengguna atau mendaftarkan bagian namespace URL untuk proses.

UrlPrefix Format

UrlPrefix memiliki sintaks berikut:

"scheme://host:port/relativeURI"

Elemen skema, host, dan port urlPrefix harus ada dan tidak kosong, dan harus mematuhi aturan berikut:

Skema

Harus http atau https, semuanya dalam huruf kecil.

Host

Harus berupa nama domain yang sepenuhnya memenuhi syarat, string harfiah IPv4 atau IPv6, atau kartubebas. Tidak seperti skema, yang harus huruf kecil, bagian host tidak peka huruf besar/kecil. Bergantung pada bagaimana bagian hostnya ditentukan, UrlPrefix termasuk dalam salah satu dari empat kategori perutean berikut, yang dijelaskan secara lebih rinci di bawah ini:

Kartubebas yang kuat
Eksplisit
Kartubebas lemah yang terikat IP
Kartubebas lemah

Port

String numerik desimal yang tidak dimulai dengan nol dan yang mewakili nomor port TCP yang valid (1 hingga 65.535). Nilai ini tidak boleh berupa kartubebas.

relativeURI

Elemen relativeURI bersifat opsional, tetapi jika ada harus selalu diikuti oleh karakter garis miring ("/"). Ini adalah string awalan yang menunjukkan subtree dalam namespace layanan komputer yang ditentukan relatif terhadap nilai skema, host, dan port. Tidak seperti skema, yang harus huruf kecil, bagian relativeURI tidak peka huruf besar/kecil.

Contoh UrlPrefix yang terbentuk dengan benar adalah:

  • https://www.adatum.com:80/vroot/
  • https://adatum.com:443/secure/database/
  • https://+:80/vroot/

Kategori Host-Specifier

Untuk fleksibilitas dan kemudahan penggunaan, HTTP Server API mendukung empat cara berbeda untuk menentukan host. Empat kategori penentu host tercantum di bawah ini dalam urutan prioritas:

Kartubebas yang kuat (Tanda Plus)

Ketika elemen host UrlPrefix terdiri dari tanda plus tunggal (+), UrlPrefix cocok dengan semua nama host yang mungkin dalam konteks skema, port, dan elemen relativeURI-nya, dan termasuk dalam kategori wildcard yang kuat.

Wildcard yang kuat berguna ketika aplikasi perlu melayani permintaan yang ditujukan ke satu atau beberapa relatifURI, terlepas dari bagaimana permintaan tersebut tiba di komputer atau situs apa yang mereka tentukan di header Host mereka. Penggunaan wildcard yang kuat dalam situasi ini menghindari kebutuhan untuk menentukan daftar lengkap host dan/atau alamat IP.

Eksplisit

Nama host eksplisit seperti nama domain yang sepenuhnya memenuhi syarat di elemen host menempatkan UrlPrefix dalam kategori eksplisit. Elemen host semacam ini dicocokkan langsung dengan header Host permintaan masuk.

Spesifikasi host eksplisit berguna untuk aplikasi multi-situs seperti server Web yang mengirimkan konten yang berbeda tergantung pada situs tempat permintaan diarahkan.

Kartubebas lemah yang terikat IP

Ketika alamat IP muncul sebagai elemen host, maka UrlPrefix termasuk dalam kategori Wildcard Lemah yang terikat IP. UrlPrefix semacam ini cocok dengan nama host apa pun untuk antarmuka IP yang ditentukan dengan skema, port, dan relativeURI yang ditentukan, dan yang belum dicocokkan dengan wildcard yang kuat atau UrlPrefix eksplisit. Alamat IP mengambil salah satu dari dua bentuk dalam elemen host:

IPv4 Literal String

Harfiah IPv4 terdiri dari empat angka desimal putus-putus, masing-masing dalam rentang 0-255, seperti 192.168.0.0.

IPv6 Literal String

String harfiah IPv6 diapit dalam tanda kurung siku dan berisi angka heksa yang dipisahkan oleh titik dua; misalnya: [::1] atau [3ffe:ffff::6ECB:0101].

Penentu host kartubebas lemah terikat IP ditujukan untuk aplikasi yang memvariasikan konten yang mereka layani berdasarkan rute yang diambil oleh permintaan masuk. Jangan mengandalkan penentu host kartubebas lemah yang terikat IP untuk menegakkan keamanan.

Kartubebas lemah (tanda bintang)

Ketika tanda bintang (*) muncul sebagai elemen host, maka UrlPrefix termasuk dalam kategori wildcard yang lemah. UrlPrefix semacam ini cocok dengan nama host apa pun yang terkait dengan skema, port, dan relativeURI yang ditentukan yang belum dicocokkan dengan wildcard yang kuat, eksplisit, atau URLPrefix kartubebas lemah yang terikat IP.

Spesifikasi host ini dapat digunakan sebagai catch-all default dalam beberapa keadaan, atau dapat digunakan untuk menentukan bagian besar namespace URL tanpa harus menggunakan banyak UrlPrefixes.

Deteksi Konflik UrlPrefix Selama Reservasi dan Pendaftaran

Untuk tujuan reservasi dan pendaftaran, empat kategori UrlPrefix yang berbeda diperlakukan secara terpisah, tanpa merujuk satu sama lain. Dimungkinkan untuk mendaftarkan UrlPrefix yang bertentangan selama mereka berada dalam kategori yang berbeda. Hanya dalam kategori yang sama yang berkonflik menyebabkan upaya reservasi gagal.

Misalnya, dimungkinkan untuk memesan UrlPrefix https://www.adatum.com:80/vroot/ eksplisit dan UrlPrefix https://+:80/vroot/wildcard yang bertentangan, karena termasuk dalam kategori yang berbeda. Namun, upaya berikutnya untuk memesan https://+:80/vroot/ ke pengguna yang berbeda akan gagal karena akan bertentangan dengan reservasi yang ada dalam kategorinya sendiri.

Perilaku Perutean

Saat merutekan permintaan HTTP masuk, API Server HTTP dimulai dengan kategori wildcard yang kuat dan membandingkan URL masuk dengan UrlPrefix yang terdaftar dan dipesan dalam kategori tersebut.

Jika URL masuk cocok dengan reservasi tetapi bukan pendaftaran, API Server HTTP akan gagal dalam permintaan. Hal ini mencegah pendaftaran berprioritas lebih rendah untuk dapat mengambil permintaan yang tidak dimaksudkan untuk itu. Status kegagalan adalah 400 ("Permintaan Buruk") daripada 503 ("Layanan tidak tersedia"), karena pengembalian 503 terkadang salah ditafsirkan oleh gateway penyeimbangan beban seperti yang menunjukkan bahwa server kelebihan beban.

Jika pendaftaran yang cocok ditemukan dalam kategori, permintaan dirutekan ke antrean permintaan yang terkait dengan pendaftaran tersebut. Permintaan selalu dirutekan ke antrean yang terkait dengan UrlPrefix yang paling cocok dalam kategori.

Jika tidak ada kecocokan yang ditemukan dalam kategori, maka HTTP Server API melanjutkan ke kategori eksplisit dan mengulangi prosedur yang sama. Untuk meringkas, urutan di mana kategori diperiksa adalah sebagai berikut:

  1. Kartubebas yang kuat
  2. Eksplisit
  3. IP-Bound kartubebas lemah
  4. Kartubebas lemah

Jika tidak ada kecocokan yang ditemukan dalam salah satu kategori, HTTP Server API mengirimkan respons dengan kode status 400 untuk menunjukkan bahwa permintaan tidak dapat dirutekan.

Aturan Kecocokan Terpanjang

Dalam setiap kategori UrlPrefix, HTTP Server API merutekan permintaan ke antrean yang terkait dengan UrlPrefix yang paling cocok. Misalnya, misalkan dua UrlPrefix berikut didaftarkan ke antrean yang berbeda:

  • Queue1 https://www.adatum.com:80/
  • Queue2 https://www.adatum.com:80/dir/sna/

HTTP Server API merutekan permintaan https://www.adatum.com:80/default.htm ke Queue1, dan permintaan untuk https://www.adatum.com:80/dir/sna/snadefault.htm ke Queue2. Ini merutekan permintaan untuk https://www.adatum.com:80/dir/app.htm ke Queue1 karena kecocokan lengkap terpanjang adalah dengan https://www.adatum.com:80/ UrlPrefix, bukan dengan https://www.adatum.com:80/dir/sna UrlPrefix.