Dlaczego końcowy ukośnik w serwisie jest tak ważny?

Question

Testowałem usługę internetową w PHP i Pythonie. Adres usługi internetowej był, powiedzmy, http://my.domain.com/my/webservice. Kiedy testowałem usługę internetową w PHP używając tego adresu URL wszystko działało dobrze. Ale kiedy użyłem tej samej lokalizacji, ale w Pythonie używając SOAPpy, dostałem błąd.

Poniżej znajduje się kod użyłem do komunikowania się z usługą internetową (Python):

from SOAPpy import WSDL 
server = SOAPProxy('http://my.domain.com/my/webservice', namespace) 
server.myFunction() 

reagują mam z serwera:

HTTPError: <HTTPError 301 Moved Permanently> 

dowiem się, że jeśli dodać końcowe ukośnik do lokalizacji usługi sieciowej, która działa!

from SOAPpy import WSDL 
server = SOAPProxy('http://my.domain.com/my/webservice/', namespace) 
server.myFunction() 

Dlaczego brak ukośnego ukośnika powoduje błąd?

Answer 1

To są różne adresy URL. http://my.domain.com/my/webservice implikuje plik webservice w folderze . http://my.domain.com/my/webservice/ oznacza domyślny dokument w folderze my/webservice.

Wiele serwerów internetowych automatycznie poprawi takie adresy URL, ale nie jest to wymagane.

Answer 2

Ponieważ rzeczywista URL serwera: http://my.domain.com/my/webservice/

Biblioteka PHP musi być następujący przekierowań domyślnie.

Answer 3

[Zastrzeżenie: To jest kopia mojej odpowiedzi from here. Wiem, że niektórzy ludzie nie lubią tego rodzaju kopiowanie, ale to wyjaśnia, dlaczego łamane jest ważne.]

Wyobraź sobie służyć stronę

http://mydomain.com/bla 

zawierający

<a href="more.html">Read more...</a> 

na kliknij , przeglądarka użytkownika będzie pobierać http://mydomain.com/more.html. Gdybyś zamiast serwowane

http://mydomain.com/bla/ 

(o tej samej treści), przeglądarka będzie pobierać http://mydomain.com/bla/more.html. Aby uniknąć tej niejednoznaczności, przekierowanie dołącza ukośnik, jeśli adres URL wskazuje na katalog.

Answer 4

Błąd to przekierowanie 301 oznaczające przekierowanie do adresu URL z ukośnikiem na końcu przez serwer WWW.

Wygląda na to, że PHP automatycznie prześledzi to przekierowanie, a zatem nie wyrzuci błędu, a Python nie. Trzeba będzie wykonać następujące czynności:

1. spróbuje połączyć się z początkowej zawartości
2. Złap każdy przekierowanie 301 i ewentualnie 302 przekierowuje także
3. Jeśli nie było przekierowanie następnie spróbuj połączyć się z tego adresu URL zamiast .

Nowy adres URL powinien być dostępny w nagłówkach odpowiedzi.

HTH.

Answer 5

To, jak wygląda SOAP-URL, zależy od serwera i implementacji SOAP.

W twoim przypadku zakładam, że serwer docelowy jest serwerem apache, a adres URL SOAP jest katalogiem zawierającym skrypt obsługi SOAP. Po uzyskaniu dostępu do serwera http://my.domain.com/my/webservice, apache decyduje, że katalog jest poprawnie adresowany jako http://my.domain.com/my/webservice/ i wysyła przekierowanie 301.

SOAP używa http POST, do klienta, aby zdecydować, czy należy zastosować przekierowanie, czy nie, zakładam, że po prostu się nie spodziewa.

Inne implementacje SOAP, np. Oś Apache w Javie ma adresy URL, które wyglądają jak Serwlety, np. http://domain.com/soap/webservice bez ukośnika, w tym przypadku adres URL bez ukośnika jest poprawny, nie istnieje żaden katalog i tak istnieje.

Osi się też nie udaje przekierować.