Udostępnij za pośrednictwem

Ciągi urlPrefix

  • Artykuł

W interfejsie API serwera HTTP UrlPrefix to ciąg Unicode o szerokim znaku (UTF-16) z kanonicznym formularzem określającym sekcję przestrzeni nazw url. Służy do zarezerwowania sekcji przestrzeni nazw adresów URL dla konta użytkownika lub zarejestrowania sekcji przestrzeni nazw adresu URL dla procesu.

UrlPrefix Format

Prefiks url ma następującą składnię:

"scheme://host:port/relativeURI"

Schemat, host i elementy portów urlPrefix muszą być obecne i niepuste i muszą być zgodne z następującymi regułami:

schemat

Musi być albo http, albo https, wszystkie w małych literach.

host

Musi być w pełni kwalifikowaną nazwą domeny, ciągiem literału IPv4 lub IPv6 albo symbolem wieloznacznymi. W przeciwieństwie do schematu, który musi być małymi literami, część hosta jest bez uwzględniania wielkości liter. W zależności od sposobu określenia części hosta prefiks UrlPrefix należy do jednej z następujących czterech kategorii routingu, które zostały opisane bardziej szczegółowo poniżej:

Silne symbole wieloznaczne
Wyraźny
Słabe symbole wieloznaczne powiązane z adresem IP
Słabe symbole wieloznaczne

port

Ciąg liczbowy dziesiętny, który nie zaczyna się od zera i reprezentuje prawidłowy numer portu TCP (od 1 do 65 535). Ta wartość nie może być symbolem wieloznacznymi.

względny identyfikatorURI

Element względnego identyfikatoraURI jest opcjonalny, ale jeśli jest obecny, musi zawsze występować znak ukośnika ("/"). Jest to ciąg prefiksu wskazujący poddrzewo w przestrzeni nazw maszyny określonej względem wartości schematu, hosta i portu. W przeciwieństwie do schematu, który musi być małymi literami, część względnego identyfikatoraURI jest niewrażliwa na wielkość liter.

Przykłady poprawnie utworzonych prefiksów url to:

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

kategorie Host-Specifier

W celu zapewnienia elastyczności i łatwości użycia interfejs API serwera HTTP obsługuje cztery różne sposoby określania hostów. Cztery kategorie specyfikatora hosta są wymienione poniżej w kolejności pierwszeństwa:

silne symbole wieloznaczne (znak plus)

Gdy element hosta urlPrefix składa się z pojedynczego znaku plus (+), urlPrefix pasuje do wszystkich możliwych nazw hostów w kontekście jego schematu, portów i względnych elementów identyfikatoraURI i należy do silnej kategorii symboli wieloznacznych.

Silna symbol wieloznaczny jest przydatna, gdy aplikacja musi obsługiwać żądania skierowane do co najmniej jednego względnego identyfikatora URI, niezależnie od tego, jak te żądania docierają do maszyny lub jakiej witryny określają w nagłówkach hosta. Użycie silnego symbolu wieloznacznych w tej sytuacji pozwala uniknąć konieczności określenia wyczerpującej listy hostów i/lub adresów IP.

jawne

Jawna nazwa hosta, taka jak w pełni kwalifikowana nazwa domeny w elemencie hosta, umieszcza prefiks UrlPrefix w kategorii jawnej. Ten rodzaj elementu hosta jest dopasowywany bezpośrednio do nagłówków hostów żądań przychodzących.

Jawne specyfikacje hosta są przydatne w przypadku aplikacji z wieloma witrynami, takich jak serwery sieci Web, które dostarczają inną zawartość w zależności od witryny, do której zostało skierowane żądanie.

słabe symbole wieloznaczne powiązane z adresem IP

Gdy adres IP jest wyświetlany jako element hosta, adres URLPrefix należy do kategorii Słabe symbole wieloznaczne powiązane z adresem IP. Ten rodzaj adresu URLPrefix jest zgodny z dowolną nazwą hosta dla określonego interfejsu IP z określonym schematem, portem i względnym identyfikatorem URL, który nie został jeszcze dopasowany przez silne symbole wieloznaczne lub jawne UrlPrefix. Adres IP przyjmuje jedną z dwóch formularzy w elemmencie hosta:

ciąg literału IPv4

Literał IPv4 składa się z czterech liczb dziesiętnych kropkowanych, z których każda mieści się w zakresie od 0 do 255, na przykład 192.168.0.0.

ciąg literału IPv6

Ciąg literału IPv6 jest ujęta w nawiasy kwadratowe i zawiera liczby szesnastkowe rozdzielone dwukropkami; na przykład: [::1] lub [3ffe:ffff::6ECB:0101].

Specyfikatory hostów ze słabymi symbolami wieloznacznymi związane z adresem IP są przeznaczone dla aplikacji, które różnią się zawartością obsługiwaną na podstawie trasy odbieranej przez żądania przychodzące. Nie należy polegać na specyfikatorach hostów ze słabymi symbolami wieloznacznymi powiązanymi z adresem IP w celu wymuszenia zabezpieczeń.

słabe symbole wieloznaczne (gwiazdka)

Gdy gwiazdka (*) jest wyświetlana jako element hosta, element UrlPrefix należy do słabej kategorii symboli wieloznacznych. Ten rodzaj adresu URLPrefix jest zgodny z dowolną nazwą hosta skojarzona z określonym schematem, portem i identyfikatorem względnym, który nie został jeszcze dopasowany przez silne symbole wieloznaczne, jawne lub powiązane ze słabym symbolem wieloznacznymi adres URLPrefix.

Ta specyfikacja hosta może być używana jako domyślna wartość catch-all w niektórych okolicznościach lub może służyć do określania dużej sekcji przestrzeni nazw adresów URL bez konieczności używania wielu prefiksów UrlPrefixes.

Wykrywanie konfliktów adresu URLPrefix podczas rezerwacji i rejestracji

W celach rezerwacji i rejestracji cztery różne kategorie UrlPrefix są traktowane oddzielnie, bez odwołowywania się do siebie. Istnieje możliwość zarejestrowania konfliktowych prefiksów UrlPrefixes, o ile znajdują się one w różnych kategoriach. Tylko w tej samej kategorii występuje konflikt, co powoduje niepowodzenie próby rezerwacji.

Na przykład można zarezerwować zarówno jawne https://www.adatum.com:80/vroot/ UrlPrefix, jak i sprzeczne silne wieloznaczne adresy URLPrefix https://+:80/vroot/, ponieważ należą do różnych kategorii. Jednak kolejna próba zarezerwowania https://+:80/vroot/ dla innego użytkownika zakończy się niepowodzeniem, ponieważ spowoduje konflikt z istniejącą rezerwacją w własnej kategorii.

Zachowanie routingu

Podczas kierowania przychodzącego żądania HTTP interfejs API serwera HTTP rozpoczyna się od silnej kategorii symboli wieloznacznych i porównuje przychodzący adres URL zarówno z zarejestrowanymi, jak i zastrzeżonymi prefiksami url w tej kategorii.

Jeśli przychodzący adres URL pasuje do rezerwacji, ale nie rejestracji, interfejs API serwera HTTP zakończy się niepowodzeniem żądania. Uniemożliwia to rejestracjom o niższym priorytcie możliwość odbierania żądań, które nie są dla niego przeznaczone. Stan niepowodzenia to 400 ("Nieprawidłowe żądanie"), a nie 503 ("Usługa niedostępna"), ponieważ zwracany błąd 503 jest czasami błędnie interpretowany przez bramy równoważenia obciążenia, co wskazuje, że serwer został przeciążony.

Jeśli znajduje się zgodna rejestracja w kategorii, żądanie jest kierowane do kolejki żądań skojarzonej z tą rejestracją. Żądanie jest zawsze kierowane do kolejki skojarzonej z najdłuższym pasującym adresem URLPrefix w kategorii.

Jeśli w kategorii nie znaleziono dopasowania, interfejs API serwera HTTP przechodzi do kategorii jawnej i powtarza tę samą procedurę. Podsumowując, kolejność, w jakiej są badane kategorie, jest następująca:

  1. Silne symbole wieloznaczne
  2. Wyraźny
  3. IP-Bound słabe symbole wieloznaczne
  4. Słabe symbole wieloznaczne

Jeśli nie znaleziono dopasowania w żadnej z kategorii, interfejs API serwera HTTP wysyła odpowiedź z kodem stanu 400, aby wskazać, że nie można kierować żądania.

Najdłuższa reguła dopasowania

W każdej kategorii UrlPrefix interfejs API serwera HTTP kieruje żądanie do kolejki skojarzonej z najdłuższym pasującym adresem URLPrefix. Załóżmy na przykład, że następujące dwa prefiksy UrlPrefixes są zarejestrowane w różnych kolejkach:

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

Interfejs API serwera HTTP kieruje żądanie https://www.adatum.com:80/default.htm do kolejki Queue1 i żądanie https://www.adatum.com:80/dir/sna/snadefault.htm do kolejki2. Kieruje żądanie https://www.adatum.com:80/dir/app.htm do kolejki Queue1, ponieważ najdłuższe dopasowanie jest zgodne z https://www.adatum.com:80/ UrlPrefix, a nie z https://www.adatum.com:80/dir/sna UrlPrefix.