Publikujemy w Web 3.0 – część 5: Sprawdzamy nasz system przekierowań HTTP 303

16gru/09

Publikujemy w Web 3.0 – część 5: Sprawdzamy nasz system przekierowań HTTP 303

W poprzednim odcinkach serii "Publikujemy w Web 3.0" pisaliśmy dostarczaniu typów dokumentów zgodnych z oczekiwaniami klientów przy wykorzystaniu przekierowań 303 w protokole HTTP. Ale skąd tak na prawdę wiadomo czy nasz serwis robi to poprawnie ? Zanim zaczniemy zadawać pytania "Pedantycznej Sieci", warto zrobić podstawowe sprawdzenie we własnym zakresie.

Receptę na nasz problem opisał na swoim blogu Richard Cyganiak, z DERI Galway.

Do przetestowania naszego systemu potrzebujemy programu curl. Jeżeli korzystamy z linuxa jest duża szansa, że będzie już zainstalowany. W przypadku Mac OSX możemy go łatwo pobrać i zainstalować. Niestety w przypadku systemu Windows - najlepszym rozwiązaniem będzie zainstalowanie sobie środowiska Cygwin oraz paczki curl.

Po zainstalowaniu komenda curl umożliwia nam pobranie informacji znajdujących się pod podanym adresem URL.

curl http://www.semanticschool.com/

zwróci nam zawartość dokumentu HTML głównej strony Szkoły Web 3.0

curl -I http://www.semanticschool.com/

zwróci nam sam nagłówek protokołu HTTP informujący o głównej stronie Szkoły Web 3.0

  HTTP/1.1 200 OK
  Date: Sun, 13 Dec 2009 21:40:48 GMT
  Server: Apache
  X-Powered-By: PHP/5.2.9
  X-Pingback: http://www.semanticschool.com/xmlrpc.php
  Vary: Accept-Encoding
  Content-Type: text/html; charset=UTF-8

curl -I http://www.openvocabulary.info/thesauri/ot/pl/instances/wordsense-dom-9

zwróci nam podobny nagłówek HTTP do poprzedniego, jednak na uwagę zasługuje wpis o statusie 303 i nowej lokalizacji do której powinno nastąpić przekierowanie.

 HTTP/1.1 303 See Other
  Date: Sun, 13 Dec 2009 21:43:44 GMT
  Server: Apache/2.2.8 (Fedora)
  Set-Cookie: JSESSIONID=A69D4C95449EAF3148EB6980804F9828; Path=/
  Location: http://www.openvocabulary.info/html/thesauri/ot/pl/instances/wordsense-dom-9
  Connection: close
  Content-Type: text/html;charset=UTF-8

Teraz wystarczy tylko przekonać serwis Open Vocabulary, że jesteśmy agentem semantycznym prosząc o treści w formacie RDF. W tym celu razem z zapytaniem HTTP GET do serwisu, wysyłamy również nagłówek informujący o oczekiwanej treści: Accept: application/rdf+xml

curl -I -H "Accept: application/rdf+xml" http://www.openvocabulary.info/thesauri/ot/pl/instances/wordsense-dom-9

tym razem przekierowanie następuje do dokumentu RDF:

  HTTP/1.1 303 See Other
  Date: Sun, 13 Dec 2009 21:46:44 GMT
  Server: Apache/2.2.8 (Fedora)
  Set-Cookie: JSESSIONID=15369544CC3DB2694D104F721CC0AD43; Path=/
  Location: http://www.openvocabulary.info/rdf/thesauri/ot/pl/instances/wordsense-dom-9
  Connection: close
  Content-Type: text/rdf;charset=UTF-8

Jeśli sprawdzamy nasz serwis, to zwracajmy uwagę na nagłówki Location otrzymywane dla różnych nagłówków Accept w zapytaniach HTTP GET. Dla każdego z wspieranych typów dokumentów, np.: HTML, RDF, JSON, przekierowanie powinno następować do istniejącego dokumentu w danym formacie. Zazwyczaj możemy też przyjąć, że domyślne przekierowanie powinno następować do (istniejącej) wersji dokumentu w formacie HTML.

Enjoy this article?

Rozpocznij subskrybcję dzięki RSS!

Tagged as: 303, curl, cygwin, debug, http, linux, macos x, przekierowanie, redirect, sprawdzenie, windows

Komentarze (2) Trackbacks (1) ( subskrybuj komentarze w tej wiadomości )

wmalota
Grudzień 26th, 2009 - 11:37

Witajcie. Najpierw chciałbym napisać, że jest to bardzo ciekawy blog. Gratuluję autorom pomysłu i życzę wytrwałości. Teraz do rzeczy.
Zastanawia mnie opisana koncepcja przekierowań. Stosując ją otrzymujemy de facto dwa adresy:
1. http://www.strona.pl/html/artykul – znajduje się tutaj artykuł w formacie html
2. http://www.strona.pl/rdf/artykul – znajdują się tutaj dane zapisane w standardzie RDF.

W tym sposobie nie podoba mi się to, że adres ze stroną dla użytkownika ma adres http://www.strona.pl/html/ zamiast http://www.strona.pl/.
Przyszła mi zatem następująca myśl do głowy. Czy adresy URI zasobów dla człowieka i maszyny muszą się w ogóle różnić? Przecież zarówno przeglądarka internetowa jak i agent semantyczny może posługiwać się adresem http://www.strona.pl/artykul (bez określenia typu zasobu). Serwer nie musi także generować przekierowania 303 do URI określającego typ zasobu. Gdy agent (semantyczny lub przeglądarka) odwoła się do zasobu http://www.strona.pl/html/artykul to serwer od razu może zwrócić zawartość w odpowiednim formacie kierując się nagłówkiem Accept wysyłanym w żądaniu http bez konieczności generowania przekierowania. Czyż nie?

[Translate]
- Sebastian Kruk
  Grudzień 27th, 2009 - 21:57
  
  Postaram się odpowiedzieć najkrócej jak się daje na Twoje (całkiem trafne) wątpliwości.
  
  1) przede wszystkim od tego jaki adres będzie miało URI użytkownika, zarówno jako identyfikator i jako strona HTMLowa, zależy tylko od Ciebie. Pisałem we wcześniejszych odcinkach tej serii, możesz się zdecydować na np schemat w którym identyfikator użytkownika to /users/13098 a strona z profilem tego użytkownika to /users/13098.html (a RDF to /users/13098.rdf). Podany przeze mnie schemat jest bardzo ogólny i zgadzam się nie zawsze “ładnie wygląda”.
  
  2) Inne pytanie – to dlaczego potrzebujemy schemat oparty na przekierowaniach HTTP 303 zamiast zwykłej negocjacji zawartości i wysyłania odpowiedniej treści w zależności agenta który z nami rozmawia. Prawdę mówiąc to w wielu przypadkach sam tak robie: kiedy mam RESTowe API, które np obsługuje profile użytkowników domyślną odpowiedzią na GET jest strona z profilem, zaś dla zapytań AJAX wygenerowanych przez prototype.js (rozpoznajemy po nagłówkach) odpowiadam i oczekuje w parametrach JSONa.
  
  Wszystko jednak się komplikuje kiedy chcemy stworzyć na prawdę semantyczny serwis, taki w którym wiadomo co jest identyfikatorem zasobu (np. użytkownika), co jest reprezentacją HTML jego profilu, a co reprezentacja RDF. Skąd konieczność rozróżnienia ? Otóż dla semantycznego agenta (szczególnie jeżeli jest “pedantyczny”) czym innym jest identyfikator zasobu, a czym innym dokument z jego opisem. Stąd też sugestia stosowania różnych schematów URI.
  
  Na zakończenie – zauważ, że jeżeli użytkownicy będą wpisywali adresy postaci /users/13098 – to nic złego się nie stanie i zostaną poprawnie przekierowani na właściwy schemat, np /users/13098.html :)
  
  Mam nadzieję, że rozwiałem cześć wątpliwości.
  
  Jeszcze raz podkreślę, że wybór różnych schematów URI i przekierowań HTTP 303, podyktowany jest “pedantycznym” podejściem do tego jak tworzymy Web 3.0 :)
  
  [Translate]