Nivertius' Beast

Kiedy myślę o sieci przyszłości wyobrażam sobie kilka rzeczy, których nie zapewnia obecna. Kiedy myślę o sieci przyszłości widzę sieć, która jest zarządzana inteligentnie, ogranicza do minimum nadprogramowy transfer, jest przyjazna dla użytkownika i dla człowieka, który rozwija ją lub aplikacje ją wykorzystujące.

Kiedy myślę o sieci przyszłości, widzę tylko REST. Widzę nowy rodzaj protokołu, proponowałbym nazwe UDTP dla czegoś w rodzaju XMLowskiego HTTP. Dlaczgo XMLowski? XMPP zdało egzamin i zasłużyło sobie na uznanie wielu ludzi i własną specyfikację.

Myślę, że taki protokół mógłby łączyć zalety HTTP - negocjacje typów, otrzymywanie reprezentacji zasobu spod konkretnego URI, potężne mechanizmy cache-owania, wraz z główną zaletą FTP - negocjacją wyboru warstwy niższego rzędu.

Gdyby taki protokół powstał, został przetestowany, udokumentowany porządnie i zrobiona przynajmniej jedna dobra implementacja to każdy by na tym skorzystał.

W obecnej sieci brakuje dobrego wykorzystania HTTP. Zacznę od braku implementacji wszystkich metod wykorzystania cache.

Ogólnie rzecz biorąc to te same zasoby sieci są wielokrotnie przesyłane tymi samymi łączami. Bardzo dużo danych jest żądanych powtórnie bez powodu. Przykład? Chyba żadna przeglądarka nie wysyła If-Modified-Since dla stron. Do serwera spokojnie tą obsługę można dodać, przeglądarka wysyła odpowiedni nagłówek, ja sprawdzam datę czy coś nowego się pojawiło i jeżeli tak, to odsyłam nową stronę, jeżeli nie, odsyłam 304 Not Modified. Zamiast 20kB strony odsyłam <2kB nagłówków.

Gdyby mechanizmy cache-owania w klientach działały lepiej, to myślę, że spokojnie ogólna ilość wykorzystanego transferu mocno by spadła i na tym zyskaliby wszyscy.

Oczywiście cache nie musi być na podstawie daty - można przecież także wykorzystywać jakiś rodzaj hasha reprezentacji zasobu, E-Tag dobrze działa dla obrazków, więc czemu nie mógłby być obliczany dla stron XHTML?

Dlaczego REST a nie XMLRPC? Wg. mnie XMLRPC to tylko dokładanie niepotrzebnego poziomu. Jeżeli można uzyskać dane, to można je uzyskać przez GET, jeżeli trzeba dodać nowe - do tego służy POST. Zmiana? Od tego jest PUT. Do usunięcia jest DELETE. Nie potrafię sobię wyobrazić sytuacji, w której by nie można zrobić przez REST. Dla przykładu - wysyłanie e-maili przez REST.

Niestety REST wymaga nowego sposobu myślenia. Przykładowo, nie wysyłam żądania zapisu, to ja coś wkładam do czyjegoś zasobu.

Nowa sieć to nowy rodzaj autentykacji. Każdy serwis implementuje autentykacje inaczej. Najczęsciej jest to robione przez parowanie ciasteczka z ID odpowiedniej sesji z danymi tej sesji. W PHP robi się to bardzo prosto. Jednak to ma ogromną wadę - nie ma jednego standardu autentykacji, wszędzie trzeba się logować w różny sposób.

RFC 2617 specyfikuje dwie metody autentykacji przez HTTP. Na nielicznych stronach można czasem, z rzadka zobaczyć logowanie przez HTTP i to najczęściej w tej prostszej wersji - Basic.

Ten system autentykacji może być naprawdę dobrym rozwiązaniem, jeżeli zostanie powszechnie zaimplementowany. Agenty odbierające dane mogą automatycznie się logować lub gdy tylko dostaną 401 Unauthorized. Implementacja takiego algorytmu logowania w kliencie jest banalna, sprowadza się do użycia base64 i wysłania dodatkowego nagłówka. Implementacja autentykacji na losowym serwisie, który używa logowania przez formularz wymaga albo napisania jakiegoś algorytmu rozpoznającego jak się logować, albo wykorzystania bazy danych do konkretnych serwisów.

Przykład? FeedReader z możliwością oglądania wpisów na poziomach przeznaczonych dla konkretnego użytkownika.

Niestety największym problemem autentykacji przez HTTP jest dla ludzi tworzących strony niemożliwość wylogowania. Muszą oni używać jakichś kruczków, np. zmieniać Realm, żeby użytkownik przestał wysyłać nagłówek WWW-Authenticate. Gdzie leży wina? Po stronie programistów klientów HTTP, w tym przeglądarek. Aplikacja używająca HTTP powinna mieć możliwość zapomnienia autentykacji. Jeżeli przestanie wysyłać nagłówek, to natychmiast zostanie wylogowana.

Oczywiście dochodzi do tego jeszcze kwestia bezpieczeństwa. Skoro użytkownik i hasło, nawet pozornie zamaskowane przez base64 jest wysyłany w nagłówku to można chociażby wysłać taki sam nagłówek, żeby się pod kogoś podszyć. Na szczęście tutaj przychodzi z pomocą SSL, który jest dość rozpowszechniony. Szyfrowanie asymetryczne, certyfikaty - wszystko czego potrzeba.

Jednak z SSL też się wiąże dużo problemów - gdy np. wchodzimy na stronę banku przez SSL to obrazki z tej strony dostajemy także po SSL? Po co szyfrować zawartość, która jest ogólnodostępna? Dlatego też nowy protokół powininen specyfikować jakiś rodzaj możliwości przełączania w czasie rzeczywistym pomiędzy strumieniem szyfrowanym a nieszyfrowanym. W tej chwili to można rozwiązać tylko tak, że niektóre linki mają scheme https, a niektóre http, tylko najczęściej twórcom serwisu się nie chce, więc wszystko idzie po SSL.

Ogólnie rzecz biorąc sieć nie powinna być zmieniana przez tworzenie aplikacji Web2.0 [ostatnio takie to popularne]. Sieci trzeba zmienić podstawy, podejście do rozwiązywania różnorodnych problemów i przede wszystkim rozpatrzenie co w sieci zostaje nadużywane a co w ogóle nie jest używane. Niestety główną przeszkodą w stworzeniu sieci przyszłości jest jej postępująca komercjalizacja i ludzkie lenistwo. Firmy popychają swoich sieciowców, programistów i webmasterów do szybkiego załatwiania problemów, bo czas to pieniądz, co jest najczęściej przyczyną workaroundów, tworzeniem rzeczy nierozwijalnych i skrojonych do konkretnego problemu. W przyszłości taka aplikacja jest rozwijana przez dobudowywanie szczególnych przypadków rozwiązania ogólnego problemu, co kończy się później porzuceniem projektu, zamknięciem strony lub przepisaniem wszystkiego łamiącym kompatybilność wsteczną.

Niestety doczekaliśmy się czasu, w którym przyszła pora na sieć. Tak, oczywiście możemy dalej kontynuować ciągłe obchodzenie tych samych błędów naszych poprzedników. Jednak i tak w przyszłości będzie moment, w którym trzeba będzie postąpić radykalnie i zmienić założenia. Pytanie brzmi dlaczego tego nie zrobić właśnie teraz, póki jeszcze nie jest tak wiele do porzucenia i można się pokusić o jakieś metody załatwiające kompatybilność wstecz?

Zrobiłem małe testy obsługi SVG w przeglądarkach, które wypadły bardzo nieciekawie. Zrobiłem strone testującą SVG wewnątrz XHTML na której zamieściłem wszystkie sposoby zamieszczenia SVG jakie mi przyszły do głowy.

Testy na mojej maszynie wypadły tak, że Firefox i Konqueror wyświetlił tylko obrazek z tagu object. Opera nie wyświetliła żadnego.

Liczę na Wasze komentarze:

• Czy istnieją jeszcze jakieś sposoby umieszczenia SVG w dokumencie XHTML?
• Czy u Was w przeglądarkach wyświetliło się to jakoś inaczej niż mi?