Nivertius' Beast

Wprowadziłem na Jabbie obsługę cache-owania stron przez HTTP. To znaczy teraz każda strona ma swoją datę ostatniej modyfikacji i Etag i jeżeli klient to obsługuje i wyśle odpowiednie nagłówki to może dostać '304 Not modified'. Zrobiłem to dla większości stron, jednak przede wszystkim chodziło mi o RSS.

Spokojnie - data modyfikacji jest obliczana na podstawie czegokolwiek co się mogło zmienić. Dla przykładu - jeżeli został dodany komentarz do wpisu, to data modyfikacji strony głównej też się zmienia [pod warunkiem, że ten wpis znajduje się na stronie głównej]. I tak większość przeglądarek tego nie obsługuje dla stron. Czytniki RSS - owszem.

Jeżeli jednak ktoś zauważyłby, że coś działa nie tak jak powinno - jak zwykle proszę od razu to do mnie zgłosić.

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?

Ostatnio przestałem kodować w XHTMLu i nie mam przemyśleń szczególnych, tylko raczej bardziej ogólne. I smutno mi jest, że jestem bezradny.

Smutno mi, że komercjalizacja sieci zatrzymała jej rozwój. Przykład? WielkiePortale nie posiadają RSS. Dlaczego? Bo człowiek jeszcze przeczyta newsa nie wchodząc na strone i nie widząc reklamy. Dlatego mało kto wie co to jest RSS. I dlatego mało kto to stosuje. I to jest odpowiedź na pytanie pewnego człowieka o to dlaczego jeden blog nie ma RSS.

Inny człowiek, który zna się na sieciach, na technologiach internetowych, w ogóle nie wiedział co to jest PUT, chodzi o metode zapytania HTTP. Poszła w zapomnienie gdy ludzie stwierdzili, że HTTP jest bierne. Teraz, gdy znów przez HTTP można zrobić wszystko aktywnie, nie wróciło. Bo przecież wszystko co można zrobić aktywnie można zrobić przez POST i wysyłanie plików. Tylko czasami PUT byłby właściwym rozwiązaniem.

Sieć niestety nie zmierza we właściwym kierunku i to wszystko przez jej komercjalizacje. Teraz strona ma być cukierkowa, ma wyglądać, ma przyciągać masy, bo większa oglądalność to większe pieniądze za reklame. Zamiast zrobić wolny zbiór informacji zrobiła się z tego papka reklam i robienia pieniędzy na użytkowniku.

I to właśnie dlatego Amaya obsługuje CSS w bardzo małym stopniu. Obsługiwała SVG zanim potrafił to Firefox. To samo z MathMLem. Dodatkowo obsługuje jeszcze XLink, który pozwala łączenie dowolnych elementów XML przez link do innego dokumentu. No i oczywiście obsługuje RDF razem z XPointerem do wstawiania uniwersalnych komentarzy do partii strony z implementacją zaszytą w przeglądarce, nie w stronie.

Ale po co to komu? Przecież już wybraliśmy swój model stron intenetowych stanowczo oddzielających się od innych rodzajów przesyłania danych. Przecież wybraliśmy, że <link> służy tylko do dołączania arkuszy stylów i RSS-ów.

I dlatego dostaliśmy Sieć na którą zasłużyliśmy.