Posts tagged: PHP - Jacek Złydach - blog

Usprawnij pracę z wyrażeniami regularnymi

Sat, 10 Aug 2013 04:49:35 +0200

Ah, dawno nic nie wrzucałem ;). Chciałbym się dziś podzielić dwoma poradami związanymi z regex'ami (wyrażeniami regularnymi). Komentarze w wyrażeniach regularnych Szybkie pytanie: co dopasowuje poniższe wyrażenie regularne?

preg_match('/.*(?=.{6,})(?=.*\d)(?=.*[a-zA-Z]).*/', $something);

Myślę, że nawet wprawionemu w bojach programiście przetworzenie tego wyrażenia zajmie krótką chwilę. W praktyce wyrażenia regularne szybko robią się skomplikowane, ekstremalnie trudne w czytaniu i jeszcze trudniejsze w debugowaniu. Można jednak te problemy rozwiązać za pomocą odrobiny formatowania i dodania komentarzy.

preg_match('/^
            .*              # Match any number of characters...
            (?=.{6,})       # ... AND match at least 6 characters (lookahead) ...
            (?=.*\d)        # ... AND match one digit after any number of characters (lookahead) ...
            (?=.*[a-zA-Z])  # ... AND match one letter after any number of characters (lookahead) ...
            .*              # ... AND allow any number of characters later.
            $/x', $password);

Prawda, że czytelniej? Modyfikator x powoduje, że wszystkie niewyescape'owane białe znaki zostaną zignorowane, a wszystko od znaku # do końca linii zostanie potraktowane jako komentarz i zignorowane. O możliwości komentowania wyrażeń regularnych dowiedziałem się z artykułu Advanced Regular Expression Tips and Techniques. Zachęcam do jego przeczytania - jest tam więcej ciekawych porad, m.in. na temat callbacków czy nadawania nazw grupom. Debugger do regexpów Istnieje świetne narzędzie do analizy i debugowania regexpów - Debuggex. Wyświetla on strukturę wyrażenia graficznie, pozwalając na analizę krok po kroku. Spójrzmy na przykład z poprzedniej części tego posta: Prawdziwa potęga tego narzędzia objawia się przy bardzo złożonych wyrażeniach regularnych, jak na przykład:

^(?:(?:ht|f)tp(?:s?)\:\/\/|~\/|\/)?(?:\w+:\w+@)?(?:(?:[-\w]+\.)+(?:com|org|net|gov|mil|biz|info|mobi|name|aero|jobs|museum|travel|[a-z]{2}))(?::[\d]{1,5})?(?:(?:(?:\/(?:[-\w~!$+|.,=]|%[a-f\d]{2})+)+|\/)+|\?|#)?(?:(?:\?(?:[-\w~!$+|.,*:]|%[a-f\d{2}])+=?(?:[-\w~!$+|.,*:=]|%[a-f\d]{2})*)(?:&(?:[-\w~!$+|.,*:]|%[a-f\d{2}])+=?(?:[-\w~!$+|.,*:=]|%[a-f\d]{2})*)*)*(?:#(?:[-\w~!$+|.,*:=]|%[a-f\d]{2})*)?$

Polecam skopiowanie powyższego wyrażenia do Debuggexa. Z jednej strony widać wyraźnie, jak ten regexp działa i do czego służy; z drugiej strony, sekcja Some random matches pokazuje, jak dziwne rzeczy przejdą przez nie poprawnie. Uwaga o wydajności wyrażeń regularnych Jak zapewne wielu programistów, którzy swą przygodę zaczęli od programowania gier, jestem sceptycznie nastawiony do wszelkich rzeczy pracujących na stringach. W szczególności, regexpy mogą na pierwszy rzut oka wydawać się wysoce niewydajne - ot skomplikowane dopasowanie tekstu zapisane w formie tekstu. Z pewnością napisanie tego w formie normalnego kodu - acz dłuższe - musi być wydajniejsze, prawda? Otóż nie. Wyrażenia regularne są tak na prawdę programem - są (bardzo skondensowanym) opisem maszyny stanów, przez którą dopasowywany tekst stopniowo przechodzi, i jeśli uda się doprowadzić tę maszynę do stanu terminalnego, to dopasowanie jest uznawane za udane. Co to dokładnie znaczy? Polecam przyglądnąć się jeszcze raz rysunkom, które tworzy Debuggex - to dokładnie struktura tejże maszyny stanów. Taki system reprezentowany jest w programie w sposób bardzo wydajny; prawdopodobnie dużo wydajniejszy od naiwnego parsera, którego moglibyśmy napisać w niewielkiej liczbie linii kodu. Co więcej, niektóre języki programowania (jak na przykład Common Lisp lub Java) pozwalają prekompilować wyrażenia regularne - jeżeli spodziewamy się, że dane wyrażenie regularne będzie używane wielokrotnie w czasie działania programu, to możemy zbudować maszynę stanów tylko raz (w przeciwieństwie do tworzenia jej na nowo za każdym razem, gdy chcemy dopasować jakiś napis), a następnie używać jej wszędzie tam, gdzie potrzebujemy korzystać z danego wyrażenia regularnego. Są nawet języki, które kompilują regexpy automatycznie.

REPL i PHP - czyli Telnetem do rakiety :)

Tue, 15 Sep 2009 16:01:00 +0200

Telneting into your rocket is sort of fundamentally cool.

Wiele języków - Lisp, Python, Perl czy Ruby posiadają tzw. pętlę wczytaj-wykonaj-wypisz - z angielskiego Read-Eval-Print Loop, czyli w skrócie REPL. Chodzi oczywiście o tryb interaktywny, w którym możemy wpisywać wyrażenia w danym języku, które są natychmiast wykonywane a rezultaty działania zwracane. Poza oczywistym zastosowaniem jakim jest mądrzejszy kalkulator :) REPL może przydawać się też do debugowania kodu, często pracującego. Python ma nawet swojego on-line REPLa do wypróbowania :) . PHP jest językiem, na którego temat można znaleźć bardzo wiele negatywnych opinii - jednak pomimo tego i tak jest szeroko wykorzystywany do tworzenia aplikacji webowych. Biorąc pod uwagę specyfikę działania skryptów PHP - są one wykonywane od nowa 'na czysto' przy każdym zapytaniu HTTP - REPL mógłby być dla tego języka przydatnym narzędziem; szkoda tylko, że autorzy tego nie uwzględnili (ściślej rzecz ujmując PHP posiada tryb interaktywny wywoływany parametrem -a, ale z bliżej mi nieznanych powodów tryb ten jest raczej krytykowany). Podczas opracowywania wyników Eksperymentu powstał problem - jak pracować na danych, których samo wyciągnięcie z bazy i przetworzenie zajmuje (na localhost'cie) ok. 1.5 minuty? Zwłaszcza kiedy jeszcze na początku nie wie się, co się chce osiągnąć? W takich sytuacjach przydaje się REPL - i na szczęście takowy dla PHP został stworzony. phpsh to projekt Facebook'a, będący Open-Source i napisany głównie... w Pythonie. Szczegóły pod adresem: http://www.phpsh.org/ Całość wykonana jest bardzo ładnie i dobrze wykorzystuje możliwość wyświetlania w konsoli kolorowego tekstu. Po rozpakowaniu na serwerze działa po prostu 'z marszu' :) . Dalsze poszukiwania pozwoliły znaleźć trzy kolejne projekty: php shell, phpa oraz pozwalający na zdalną pracę przez przeglądarkę (i potrafiący wyświetlać wyjście w HTMLu) PHP Interactive. Niech więc każdy wybierze co lubi (ja zamierzam raczej zmienić język ;) ). Przydatność narzędzia jakim jest REPL jest nieoceniona, wypadałoby zacytować pracownika NASA JPL dotyczący awarii na pokładzie sterowanego zdalnie pojazdu kosmicznego:

Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem.

Edit 15.09.2009 17:39 Fus donosi, że nawet C# ma swojego REPL'a. Podjęte też zostały próby stworzenia takiego narzędzia dla C i C++.

Eksperyment - podsumowanie

Mon, 14 Sep 2009 05:35:30 +0200

W tym wpisie znajdują się wyczekiwane przez niektórych wyniki Eksperymentu HTTP. Celem całej tej zabawy było odpowiedzenie sobie na następujące pytanie: Czy jest jakiś sposób, żeby odróżnić zapytanie o zasób osadzony na stronie od 'normalnego' zapytania? Inaczej - czy da się na przykład rozróżnić, kiedy przeglądarka pyta o obrazek osadzony za pomocą , a kiedy o sam obrazek, którego adres wpisany został bezpośrednio lub wywołany za pomocą linka? Czy da się odróżnić, kiedy ktoś osadza obrazek na swojej stronie, a kiedy tylko do niego linkuje? Jedyną rzeczą, która mogłaby zawierać takie informacje jest zapytanie HTTP wysyłane przez przeglądarkę do serwera. We wstępnych badaniach wykluczyliśmy możliwość użycia nagłówka Referer do rozróżnienia zapytań - co prawda Referer przy elementach osadzonych ma zwykle wartość odpowiadającą osadzającej stronie, ale taki sam nagłówek uzyskamy klikając w link znajdujący się na takiej stronie. Z pozostałych nagłówków żaden nie ma na celu informować o rodzaju zapytania. Okazuje się jednak, że takie rozpoznanie jest możliwe - trzeba podejść do sprawy statystycznie. Podejrzenia dość szybko padły na nagłówek Accept... Eksperyment, w którym w zeszłym tygodniu około 200 (+/-50) osób wzięło udział pozwolił mi zebrać trochę danych statystycznych. Obiektem zainteresowania było zapytanie HTTP wysyłane przez przeglądarkę przy próbie pobierania obrazka JPG i PNG celem osadzenia go na stronie (Wyniki Nagłówek Accept pozwala przeglądarce określić, jakiego typu multimediów spodziewa się w odpowiedzi na swoje zapytanie. Okazuje się, że przeglądarki spodziewając się elementu do osadzenia na stronie często wysyłają w tym nagłówku inne typy, niż w przypadku obrazków pobieranych do wyświetlenia bezpośredniego. Spójrzmy na przykład na ten wykres dla przeglądarki Firefox: Wykres ten przedstawia szansę wyświetlenia danego wpisu w nagłówku Accept w zapytaniu o obrazek osadzony (EMBEDDED) lub do wyświetlenia bezpośredniego (LINK). Różnica w zawartości nagłówków jest wyraźnie widoczna. Wykres jest znormalizowany - przeskalowany tak, że wartość 1 odpowiada sytuacji, gdy dany nagłówek wystąpił w każdym zapytaniu danego typu. Okazuje się, że w przypadku Firefoksa rodzaj zapytania mamy jak na dłoni, wystarczy spojrzeć w nagłówek Accept! Przyglądnijmy się więc wykresom dla innych przeglądarek: Opera nie daje nam najmniejszych szans - w każdym zapytaniu wysyła identyczny nagłówek Accept. Internet Explorer jak zawsze sprawia dużo radości - z jednej strony odróżnienie rodzaju zapytania zdaje się być trywialnie proste, z drugiej strony IE ma dziwną tendencję zasypywania nas specyficznymi wpisami w nagłówku. Najbardziej zabawny jest image/pjpeg, który w jednym zapytaniu potrafi wystąpić dwa razy obok siebie. Nie rozumiem przyczyn tego zjawiska, ale występuje w wersjach IE od 6 do 8. Ale obiecano mi już, że zostanie to zgłoszone do Microsoftu :). Tutaj bardzo prosto - tak samo jak w IE, zapytania osadzone mają bardzo krótki nagłówek Accept ;) Ten wykres przedstawia przeglądarki przedstawiające się jako Mozilla, które nie zaklasyfikowały się nigdzie indziej. Wykres jest analogiczny do tego od Firefoksa (tak na prawdę część z przeglądarek na tym wykresie to źle rozpoznane Firefoksy - przyczyny tego zjawiska omawiam dalej). Podobała mi się w tym wszystkim Mozilla, która przedstawiła się jako "ROBOT DO WYKRADANIA KONTENTU" :) . Google Chrome także nie robi problemów przy rozpoznaniu typu zapytania. W przypadku nierozpoznanych przeglądarek sprawa troszkę się zaciemnia, ale wciąż można zidentyfikować przeważające tendencje, które pozwalają rozróżnić rodzaj zapytania. Dla podsumowania, oto zapytania dla wszystkich przeglądarek na raz: O samym Eksperymencie Powyższy wykres przedstawia wszystkie główne rodziny przeglądarek zidentyfikowane przez skrypty (proszę nie zwracać uwagi na wartości numeryczne - odnoszą się ilości zapytań wygenerowanych przez daną przeglądarkę). Identyfikacji przeglądarek dokonywała funkcja get_browser() w PHP. Co prawda funkcja ta dość skutecznie rozdzieliła przeglądarki, jednak mimo wszystko pozostawia wiele do życzenia (mówiąc mniej formalnie - jest skopana) - nie radzi sobie z niektórymi wariacjami Firefoksa, Safari czy Chrome na systemach Apple. Dużo lepiej z deszyfrowaniem nagłówka User-Agent zdaje się radzić sobie jedna ze stron w Internecie. Serdecznie dziękuję wszystkim, którzy poświęcili swój czas i wzięli udział. Bardzo miłym akcentem było wrzucenie linku do Eksperymentu na Wykop. Ponadto dziękuję wszystkim tym, którzy zachęcali znajomych do wzięcia udziału. Pozdrawiam też użytkowników Linksa i Lynxa ;). Szczególne podziękowania dla kolegów ze Stosowanej oraz wszystkich gości z Blip'a! Zastosowania Mając możliwość rozpoznania celu zapytania o dany zasób możemy odpowiednio zareagować. Przykładowe zastosowania tej wiedzy to:

Lepsze sprawdzanie, czy ktoś nie hotlinkuje naszych zdjęć/obrazków - klasyczne używanie nagłówka Referer jest nieskuteczne i denerwujące dla osób korzystających z Google Images.
Serwowanie różnej treści zależnie od rodzaju zapytania - chyba głównie dla zabawy :)
Wybiórcze stosowanie przekierowań - serwowanie ramek maskujących adres w przypadku zapytania bezpośredniego oraz używanie np. przekierowania proxy w przypadku zapytań osadzonych.

Proof of concept Miał być, ale nie ma - próbując z Paszczakiem zaktualizować browsercaps.ini na serwerze coś zepsuliśmy ;). Z tego powodu na razie przykładu działania nie będzie - dość powiedzieć, że u mnie lokalnie działa :). Na podstawie zebranych danych wygenerowałem tabelkę w PHP pozwalającą napisać sobie skrypt rozpoznający rodzaj zapytania. Co dalej? Powstają coraz to nowe wersje przeglądarek, a wraz z nimi prawdopodobnie będzie zmieniać się zawartość nagłówka Accept. Można spróbować stworzyć system rozpoznawania zapytania oparty o filtr bayesowski lub wykorzystać inne metody pozwalające na bieżąco aktualizować stan wiedzy na temat używanych wartości nagłówków. Danych, które zebrałem nie było strasznie dużo, ale jeżeli ktoś chce poddać je dalszej analizie to chętnie je udostępnię :) . Edit Dla wytrwałych bajka o zdecydowanie pokręconych stringach User Agent :) Edit 2 Wykresy, o które prosił dr_bonzo: ~~http://temporal.pr0.pl/blog/materialy/posty/eksperyment/odwrocone Czytelniej ? :)~~zginęły przy zmianie serwera, powinny być gdzieś w backupie.

Przekierowania, skracanie i ukrywanie adresów - co i jak?

Thu, 10 Sep 2009 11:30:48 +0200

W ostatnim okresie upowszechniły się serwisy skracające adresy, takie jak tnij.org, tinyurl.com czy działający wewnątrz Blipa rdir.pl. W tym wpisie prezentuję techniki leżące u podstaw takich usług - metody przekierowywania przeglądarek i ukrywania adresów. Ponieważ 'serwis skrótowy' jest jednym z elementów projektu, nad którym pracuję, poniższy opis jest de-facto spojrzenie z perspektywy budowania usługi skracania adresów. Na koniec wspomnę też kilka słów o toczącym się Eksperymencie HTTP. mod_rewrite i przepisywanie URL Kluczem do stworzenia systemu skracania adresów jest możliwość 'przepisywania adresów' - dzięki temu nasz system będzie umiał obsłużyć adresy postaci: http://moj.system.skrotow.pl/skroconyurl. Do tego celu można wykorzystać na przykład bardzo popularny moduł mod_rewrite serwera Apache. Krótko i konkretnie temat 'ładnych linków' omówił na swojej stornie porneL. Przykład .htaccess, którego obecnie używam (nazwy związane z serwisem zmienione ;) ):

#

RewriteEngine On
RewriteBase /ACME/skrypcik/

#add trailing slash (url canonicalization)
RewriteCond	%{REQUEST_FILENAME}		-d
RewriteRule		^(.+[^/])$		$1/		[R=301,L]

RewriteCond	 %{REQUEST_FILENAME} !-f
RewriteCond	 %{REQUEST_FILENAME} !-d
RewriteRule 	^(.*)$		index.php?adres=$1		[NC,QSA,L]

#

Występuje tu kilka rzeczy, których nie omówił jeszcze porneL. Po pierwsze, dyrektywa RewriteBase - pomaga ona w poprawnym działaniu przepisywania adresów w przypadku, gdy nasza strona znajduje się w podkatalogu na serwerze. Z tą dyrektywą jest zwykle trochę zabawy, więc proszę okazywać cierpliwość ;). Nie znam prostego (w kilku zdaniach) wyjaśnienia jej roli - jeżeli ktoś umie takowe sformułować, to zachęcam do uczynienia tego w komentarzu! Po RewriteBase mamy dwie linie dokonujące usuwania slashy z URI w ramach procesu przekształcania adresu do postaci kanonicznej. Istotne (zwłaszcza dla Google) jest tutaj przekierowanie 301. Kolejne trzy linijki sprawdzają, czy żądany adres nie jest fizycznie istniejącym plikiem lub katalogiem. Podobny kod można na przykład znaleźć w .htaccess Wordpressa. Jeżeli żądany adres nie pasuje do żadnego istniejącego pliku lub katalogu na serwerze, to wywoływany jest nasz skrypt (index.php) z parametrem adres zawierającym całą końcówkę wpisaną przez użytkownika. To tyle tytułem wprowadzenia do .htaccess na praktycznym przykładzie - na temat tego modułu jest bardzo dużo materiałów w sieci - myślę, że każdy sobie poradzi. Mając już adres wpisany przez użytkownika należy jakoś odesłać mu właściwą treść. Możemy to zrobić na kilka sposobów: Przekierowania HTTP Przekierowania te dość dokładnie omawiałem w jednym z ostatnich postów. Jest to najbardziej podstawowy sposób oddania komuś żądanego zasobu ze 'skróconego' (przez termin 'skrócony adres' w tym tekście rozumiem każdej długości alias w serwisie skrótowym - nawet, jeśli jest dłuższy od oryginalnego URL :) ) adresu. Wybór kodu powinien zależeć od tego, jaką rolę pełni skrócony adres - 301 gdy zdecydujemy się przypisać go na stałe do miejsca docelowego, 302 lub 307, gdy adres docelowy może ulec zmianie. Właściwości tej metody to:

Takiego przekierowania można używać także do elementów osadzanych, np. w tagach
Nie można zamaskować adresu docelowego - jest on widoczny w pasku adresu przeglądarki.
Zwłaszcza w przypadku użycia kodu 301 PageRank przelewa się na adres docelowy (ale ostrożnie z tym).
Opiera się w całości na protokole HTTP, więc musi być wspierana przez wszystkie przeglądarki.

Ciekawostka - serwis tnij.org zdaje się odsyłać nagłówek 301 Moved Permanently, a nie 302 Found lub 307 Temporary Redirect. Przekierowania "meta refresh" Innym rodzajem przekierowania, wykonywanym całkowicie po stronie klienta, jest wymuszenie odświeżenia adresu przez przeglądarkę przy użyciu znacznika . Przykładowy kod wygląda następująco:


 
  
 
 
  Proszę, kliknij w link!

Generujemy taki kod, podstawiając odpowiedni adres. Cyfra 0 może zostać zastąpiona inną - określa ona czas w sekundach, po jakim przeglądarka powinna dokonać odświeżenia strony z nowym adresem. Własności tej metody:

Nie można zamaskować adresu docelowego - jest on widoczny w pasku adresu przeglądarki.
Chodzą wieści, że Google umie czytać ten typ przekierowania z kodu HTML - ale na rewelacyjny przelew PageRank bym nie liczył.
Może nie być wspierane przez wszystkie przeglądarki. Dlatego też powinno się umieścić w dokumencie informację o linku dla przeglądarek nie wspierających tej metody.
Znikoma przydatność.

Ponieważ w tym przypadku znacznik nadpisuje istniejący w HTTP nagłówek Refresh, istnieje też wariant tej metody nie wymagający umieszczania dodatkowego znacznika w dokumencie HTML - możemy zamiast tego wysłać dowolny HTML i wygenerować odpowiedni nagłówek HTTP w skrypcie. Przykład:

link.';
?>

Osobiście ciekawi mnie, jak przeglądarka zareagowałaby w przypadku zapytania o osadzony element (), gdyby odesłać jej obrazek razem z nagłówkiem Refresh. Być może sprawdzę to przy najbliższej okazji. Przekierowania Javascript Metoda podobna do meta refresh - wysyłamy stronę ze spreparowanym JavaScript'em, który automatycznie przekierowuje użytkownika pod inny adres. Cechy techniki:

Nie działa z elementami osadzonymi.
Wiele crawlerów nie umie obsługiwać JavaScript'u - wyszukiwarki nie zobaczą przekierowań.
Niektórzy nie posiadają lub celowo wyłączają obsługę JavaScript'u w przeglądarce.
Teoretycznie można próbować użyć jej do zamaskowania adresu docelowego zasobu w pasku adresu - niestety nie znam się aż tak na JavaScript, żeby podać przykład.

Maskowanie adresu - metoda ramek Użycie znienawidzonego znacznika pozwala bardzo skutecznie zamaskować adres docelowy strony, na którą przekierowujemy (i przy okazji zmienić jej tytuł). Wystarczy wygenerować taki oto HTML:

Własności tej metody:

Pozwala zamaskować adres docelowy i wymienić tytuł.
Nie działa z elementami osadzonymi - z oczywistych przyczyn.
Standardem są już skrypty pozwalające stronie automatycznie 'wyskoczyć z ramki' - i wtedy nici z maskowania adresu.
Może być przyczyną kontrowersji i ataków ze strony niedouczonych webmasterów stron docelowych.

Tę technikę spotykamy się wbrew pozorom dość często - na stronach takich jak Wykop.pl czy nawet Google Images. Takie strony po prostu dodają dodatkową ramkę z własnymi informacjami :). Przekierowania 'proxy' Najbardziej bezpośrednią metodą wyświetlenia cudzego contentu pod swoim adresem :) jest pobranie jej przez nasz serwer i oddanie użytkownikowi. W PHP pomóc nam w tym może funkcja readfile(). Metoda jest bardzo prosta w teorii i gwarantuje zamaskowanie adresu, jednak rodzi też szereg trudności technicznych:

Jeżeli oddajemy w ten sposób stronę internetową to najprawdopodobniej posypią się wszystkie relatywne odnośniki do obrazków, skryptów i CSS - dostaniemy goły, nieużyteczny dokument HTML.
Jeżeli oddajemy coś innego niż zwykły tekst to musimy ręcznie określić typ MIME zwracanego zasobu. A ponieważ zasób jest nie u nas, to możemy albo zgadywać ten typ (np. po rozszerzeniu), albo odczytywać dopiero po ściągnięciu. Innymi słowy - dodatkowa robota.
Cała treść przechodzi przez nasz serwer, skutecznie go spowalniając (już nie mówiąc o ewentualnych limitach downloadu).

Wspominam o tej technice, gdyż ma ona także dużo dobrych właściwości:

Kompletne zamaskowanie adresu zasobu.
Działa z elementami osadzonymi.
Pozwala nam modyfikować zasób i sposób jego przetwarzania (np. można wymusić na przeglądarce wyświetlenie okienka "Zapisz jako...").

Wspomniane przeze mnie problemy techniczne można oczywiście obejść, ale pytanie czy nie jest to przerost formy nad treścią :). Trochę ten post wyszedł przydługi... ;). A teraz obiecany na początku... Eksperyment HTTP Chciałbym w tym miejscu podziękować wszystkim osobom, które już wzięły udział i rozgłaszały Eksperyment wśród innych. Ruch pierwszego dnia był spory; jakaś dobra dusza nawet wrzuciła link na Wykop :). Zebrałem już dość dużo danych, jakieś 85% tego, co założyłem jako minimum. Dlatego jeżeli ktoś jeszcze nie brał udziału, to zapraszam, a jeżeli już brał to zachęcam o podrzucenie linka innym osobom! Myślę, że wyniki opracuję w najbliższych dniach. Dla zaostrzenia apetytu powiem tylko, że eksperyment ma duży związek z tematem tego posta :).

HTTP - Eksperyment

Wed, 09 Sep 2009 10:48:31 +0200

Aktualizacja - 12.09.2009 Eksperyment został zakończony, trwa przetwarzanie zebranych danych. Zapraszam - wyniki oraz cel samych badań już wkrótce! :) Aktualizacja - 14.09.2009 Wyniki już są :) . Drodzy Czytelnicy, w ramach prac nad pewnym projektem i poszerzaniem wiedzy n/t HTTP przeprowadzam mały eksperyment statystyczny. Każdy z Was może wziąć w nim udział i tym samym zrobić coś dla dobra Galaktyki! :). Wystarczy jedynie wejść na podaną niżej stronę eksperymentu i po załadowaniu kliknąć w oba obrazki (mają podłożone linki). Strona Eksperymentu W eksperymencie tym zbieram tylko troszkę danych na temat zapytania HTTP wysyłanego przez przeglądarkę. Wyniki i opracowanie podam po zebraniu odpowiedniej ilości danych, czyli - miejmy nadzieję - w ciągu kilku najbliższych dni. Jednocześnie bardzo prosiłbym o nie znęcanie się nade mną przez fałszowanie wyników lub hackowanie strony. Wystarczy wejść, kliknąć dwa razy i wyjść :). Z góry dziękuję wszystkim, którzy zechcą wziąć udział w eksperymencie! Wyniki wkrótce! Ważny Edit! Dziękuję tym, którzy tak ochoczo zareagowali na wezwanie do wzięcia udziału! Jednocześnie mam prośbę - jeżeli ktoś ma zainstalowane w systemie kilka przeglądarek WWW, to zachęcam do wejścia na stronę Eksperymentu każdą z nich z osobna! Dzięki temu zebrane zostanie więcej istotnych danych :).

Przekierowania HTTP

Tue, 08 Sep 2009 11:48:21 +0200

W ostatnim okresie czasu intensywnie pracuję nad pewnym projektem w PHP. Prace te pozwoliły mi się zapoznać dokładnie z różnymi technikami przekierowywania przeglądarek do żądanych zasobów. W tym poście chciałbym omówić główne przekierowania zdefiniowane w protokole HTTP; przynajmniej jedno z nich powinno być powszechnie znane programistom PHP. Wpis ten oparty jest o post "The anatomy of server sided redirect" na blogu Sebastian's Pamphlets, specyfikacji HTTP/1.1, której wydrukowany fragment trzymam obok siebie oraz osobistych doświadczeniach. Przekierowania HTTP Jak wiadomo, fundamentalny dla WWW protokół HTTP zawiera kody odpowiedzi (opisane w sekcji 10 specyfikacji RFC2616), którymi serwer WWW informuje przeglądarki o tym, co przeglądarki mają dalej robić. Nas w tym miejscu interesują kody serii 3xx (sekcja 10.3 RFC). Zadaniem tych kodów jest przekierowanie przeglądarki pod inny adres docelowy. Kody te mają też wpływ na crawlery wyszukiwarek, które przecież starają się udawać ludzi. Powiemy sobie o:

HTTP 301 Moved Permanently
HTTP 302 Found
HTTP 303 See Other
HTTP 307 Temporary Redirect

Gdy serwer dokonuje przekierowania to oprócz odpowiedniego kodu statusu i opisu wysyła także nagłówek Location zawierający adres, pod który ma udać się przeglądarka. Przykładowa odpowiedź-przekierowanie HTTP, które przeniesie przeglądarkę na stronę Google, może wyglądać następująco:

HTTP/1.1 307 Temporary Redirect
Location: http://www.google.pl

HTTP/1.1 301 Moved Permanently Kod ten tworzy permanentne przekierowanie pod adres docelowy. To tak, jakbyśmy powiedzieli przeglądarce: "URI, o które prosiłaś znikło. Być może nigdy go nie było, a na pewno nigdy nie będzie. Nie będę dostarczać żadnej treści dla zapytania o to URI, więc zaktualizuj swoje zakładki podanym niżej adresem i nie zawracaj mi już więcej głowy. Nigdy więcej.". Przekierowania 301 używamy najczęściej przy przeniesieniu całej strony, gdy chcemy poinstruować ludzi i crawlery o zmianie lokalizacji. W szczególności powinniśmy to zrobić, jeżeli zależy nam na utrzymaniu dotychczasowej pozycji strony w wyszukiwarkach. Google rozumie kod 301, ale stronę trzeba przenosić z głową. Kod 301 jest przekierowaniem 'na zawsze' - URI raz oznaczone tym numerem nie powinno być nigdy więcej używane w innym celu. To znaczy, że mamy obowiązek go utrzymywać - przynajmniej jeśli zależy nam na Page Rank - tak długo, jak to tylko możliwe (tak, trzeba płacić i za starą domenę ;)). Nie powinno się też nigdy zmieniać miejsca, do którego odsyła to przekierowanie. Kodu 301 powinniśmy używać też do tzw. sprowadzenia adresu do postaci kanonicznej (pozwala uniknąć problemów z wyszukiwarkami, w tym podwójnego widzenia treści dla adresów z www i bez www). Przykład użycia pliku .htacccess i mod_rewrite do zapewnienia postaci kanonicznej adresu:

RewriteEngine On
RewriteCond %{HTTP_HOST} !^example\.com [NC]
RewriteRule (.*) http://example.com/$1 [R=301,L]

Należy zwrócić uwagę na fragment R=301 w ostatniej linijce - oznacza to, że do zmiany adresu zostanie użyte przekierowanie 301. Aby przekierowanie 301 zostało wykonane poprawnie musimy wysłać przeglądarce tekst z kodem i statusem - w przeciwnym razie wykonane zostanie domyślne przekierowanie 302 Found, o którym niżej. Tyczy się to szczególnie PHP, gdzie już chyba zwyczajem stało się pisanie:

Header('Location: '.$adres);

Taki kod wykona przekierowanie 302. Poprawnie sformułowane w PHP przekierowanie 301:

Header('HTTP/1.1 301 Moved Permanently');
Header('Location: '.$adres);

HTTP/1.1 302 Found Przekierowanie 302 jest chyba najbardziej nadużywanym przekierowaniem w sieci - głównie z powodu tego, że jest to przekierowanie domyślne, które zostanie wykonane jeżeli samodzielnie nie wykonaliśmy innego przekierowania. Problemy dotyczą głównie niewłaściwego używania 302 w miejscu, gdzie powinno być 301 - częściowo z niechlujstwa, a częściowo - wg Simon's Pamphlets - z różnych mitów rozpowszechnianych w środowisku SEO. Pomyłkowe użycie 302 zamiast 301 jest niegroźne zarówno dla człowieka jak i przeglądarki, ale może wyrządzić krzywdę pozycji strony w wyszukiwarce. Kod 302 Found (w HTTP/1.0 zwany 302 Moved Temporarily) służy do wskazania tymczasowej lokalizacji zasobu. Ponieważ jednak przekierowanie może się zmieniać, specyfikacja sugeruje, by klienci dalej używali tego adresu, którym przyszli, a nie tego, który dostaną z przekierowania. Jeżeli chce się z jakiegoś powodu odesłać użytkownika na inną stronę - czy to wewnętrzną, czy zewnętrzną w stosunku do naszego serwisu - to możemy użyć właśnie tego kodu. W PHP wygląda to tak:

//Wersja HTTP/1.0
Header('HTTP/1.0 302 Moved Temporarily');
Header('Location: '.$adres);

//Wersja HTTP/1.1
Header('HTTP/1.1 302 Found');
Header('Location: '.$adres);

Poza niewielkimi różnicami w specyfikacji dotyczącymi cache'ingu kody 302 obu wersji robią w zasadzie to samo. I chociaż dotychczasowe (9.3) RFC (10.3.3) nie pozwalały zmieniać przy przekierowaniu metody zapytania (np. z POST na GET), większość przeglądarek to właśnie robi (przeważyły prawdopodobnie względy bezpieczeństwa) - kod 302 jest interpretowany tak jak 303. Aby można było rozróżnić, kiedy serwer chce wykonać przekierowanie ze zmianą metody zapytania na GET a kiedy bez zmiany, wprowadzono w HTTP/1.1 dwa dodatkowe kody - 303 See Other i 307 Temporary Redirect. Ponieważ przeglądarki oraz crawlery potrafią już 'rozmawiać' protokołem HTTP/1.1, to poza szczególnymi przypadkami gdy z jakiegoś powodu musimy 'bawić się' w HTTP/1.0 możemy spokojnie korzystać z nowych kodów. HTTP/1.1 303 See Other Według RFC2616 (10.3.4) celem istnienia tego kodu jest przede wszystkim umożliwienie wynikom zapytania POST możliwości przekierowania do innych zasobów. W momencie otrzymania kodu 303 przeglądarka powinna zmienić metodę zapytania na GET. Poprawne użycie w PHP:

Header('HTTP/1.1 303 See Other');
Header('Location: '.$adres);

Kodu tego powinniśmy używać w skryptach wywoływanych zapytaniem POST - po przetworzeniu żądania powinny one wykonywać przekierowanie 303 na stronę, która wyświetli nam wyniki. Dzięki temu, gdy użytkownik odświeży stronę, zapytanie POST (mogące mieć przecież jakieś skutki uboczne!) nie zostanie wykonane ponownie (Firefox w takich sytuacjach pyta, czy ponownie wysłać dane). Jest to o tyle istotne, że zgodnie ze specyfikacją do wprowadzania zmian (edycja, usuwanie, itp.) w zasobach strony powinniśmy używać metody POST, nie GET (celowo pomijam tutaj PUT i DELETE - architektura REST, która je wykorzystuje, nie jest jeszcze aż tak popularna). HTTP/1.1 307 Temporary Redirect Kod 307 to nasz najlepszy przyjaciel, gdy potrzebujemy wykonywać przekierowania do tymczasowych zasobów. W przeciwieństwie do 303 nie zmienia metody zapytania - kod 307 zachowuje się tak, jak powinien był się zachowywać w przeglądarkach 302. To właśnie tym kodem chcemy się posługiwać, więc warto zadbać o jego poprawne wysłanie, żeby przypadkiem nie wyszedł nam 302:

Header('HTTP/1.1 307 Temporary Redirect');
Header('Location: '.$adres);

Jednym z zastosowań przekierowania 307 jest przekierowywanie kanałów RSS/Atom do usługi FeedBurner. Podsumowanie - kiedy używamy którego kodu?

HTTP 301 Moved Permanently - gdy zasób został na stałe przeniesiony pod inny adres. Przekierowania 301 powinniśmy utrzymywać włączone tak długo, jak to możliwe i nigdy nie poddawać ich recyclingowi.
HTTP 302 Found - gdy musimy borykać się z protokołem HTTP/1.0.
HTTP 303 See Other - gdy skrypt, który otrzymał zapytanie POST chce wyświetlić jakieś wyniki - powinien wtedy wykonać przekierowanie 303 na stronę z wynikami. Unikniemy dzięki temu ponownego wysłania zapytania POST przy odświeżeniu strony.
HTTP 307 Temporary Redirect - wszystkie sytuacje, gdy robimy tymczasowe przekierowania. Skracanie nazw URI, odesłanie do innej strony, przekierowanie RSS/Atom na FeedBurnerm itd.

Dodatkowe informacje

Omówione przekierowania operują bezpośrednio na poziomie protokołu HTTP. Oznacza to, że możemy ich użyć do przekierowywania np. obrazków osadzanych w tagach .
Osobom używającym .htaccess do sprowadzania adresu do postaci kanonicznej (w tym np. usuwanie bądź dodawanie 'www' przed nazwą) polecam upewnić się, że używają przekierowania 301 a nie domyślnego 302.

Zainspirowany Gynvael'em i innymi postanowiłem utworzyć też dział Code Snippets, w którym znajdować się będą różne drobne i - miejmy nadzieję - przydatne fragmenty kodu. Jako pierwszy umieszczam drobną klasę PHP realizującą u mnie w projekcie przekierowania oraz obsługę wybranych kodów 4xx i 5xx.

O tworzeniu stron słów kilka...

Thu, 12 Jul 2007 12:29:14 +0200

Przez ostatnie kilka dni intensywnie tworzę sobie CMS w oparciu o PHP5 i MySQL. devBlog'a na niego raczej nie przenoszę, ale chcę na jego podstawie stworzyć kilka stron - dla siebie i nie tylko. CMS piszę w oparciu o funkcjonalność 'object-oriented' w języku PHP5. Dzięki temu, zgodnie z założeniami projektowymi, jest on już teraz w miarę rozszerzalny i przenośny. Jak postawię na nim pierwszą stronę, to opis projektu pojawi się i tutaj. W trakcie tworzenia zacząłem się zastanawiać nad sensownością używania CMSów do budowy stron internetowych wszelkiego rodzaju. W sieci do niedawna panowała taka moda, że każdy kto chce mieć dobrą stronę musi użyć jakiegoś CMSa i obowiązkowo dodać do tego forum dyskusyjne. A co bardziej ambitni tworzyli własne systemy zarządzania treścią. Ale czy kompleksowy, rozbudowany silnik strony to zawsze jest dobra droga? Weźmy dla przykładu Liryczną Galeryjkę Stanisława Wawszczaka. Strona składa się z layout'u opartego na XHTML/CSS oraz kilku narzędziowych funkcji w PHP. Zapis i odczyt komentarzy z bazy i obsługa parsera XSL. Wiersze zapisane są w plikach XML a krótki kod, oparty o parser XSL, generuje na tej podstawie zarówno wygląd strony jak i zawartość kanału RSS. Mamy więc garść prostych funkcji narzędziowych + mały parser i ładnie wyglądającą, funkcjonalną stronę, której niczego nie brakuje. Jak widać, czasem cel można osiągnąć prościej. Nie zawsze strona domowa musi obsługiwać wszystkie języki świata, cztery rodzaje baz danych, mieć forum, użytkowników, shoutbox'a i 101 innych features'ów.