> Uparcie robisz na opak :)
>
> Formularz kontaktowy _powinien_ używać POST, bo ma efekt uboczny -
> wysłanie e-maila.

Więc nie robię na opak :-) Ponadto chyba każdy submit formularza ma na celu
mieć efekt uboczny? Po to się to robi aby wysłać email, dodać do koszyka
(bazy danych) noiwą pozycję zamówienia, zaktualizować w bazie danych ilości
zamawianych produktów itp. W żadnym z tych przypadków akcja POST nie może
się powtórzyć przy np. odświeżeniu.

> Dlatego należy robić walidację danych!

Mam walidację lecz to za mało. Nie wolno np. pola nazwać "email" bo boty
spamowe wiedzą wtedy co tam wpisać. Pole powinno nazwyać się "dupa" lub coś
w tym stylu. Pozostałem pola to imię, nazwisko, treść - więc nie ma czego
walidować.

> Nie rób bezbronnych aplikacji (security by obscurity) polegając na tym jak
> bardzo komuś się (nie)chce. Zrób to porządnie tak, żeby nie było
> oczywistych dziur w użyciu danych POST, GET, cookies i innych.

Nie robię - nawet robię sporo więcej: stosuję ID transakcji a w skrajnych
przypadkach - generowanie wartości pola przez JS.

> Powiedziałem dobrym botom. Te złe i tak będą ci łaziły po wszystkich
> formularzach - GET (harvestery) i POST (spamboty).

Hmmm... założyłem, że się przejęzyczyłeś. A co to zmieni jeśli złe i tak
będą spamowały - jak sam napisałeś? Dobre przecież nie są źródłem spamu.


> Nie rozumiem o czym mówisz. Wyszukiwarka = GET. Koszyk = POST.
> Wyszukiwarka != koszyk.

Ok... może przykład. Jestem na karcie produktu. Dodaję produkt do koszyka
(np. POST), w koszyku aktualizuję ilość (POST) klikam wstecz i co dostaję? Z
pewnością nie stronę produktową lecz komunikat o próbie submitu formularza.
W "moim" podejściu te dwa POSTy nie są widoczne dla przeglądarki i wstecz
przenosi tam gdzie user oczekuje - do produktu.

> Przeglądarka wysyła POST. Obrabiasz dane, wysyłasz status 303 i nagłówek
> Location. Przeglądarka załaduje nową stronę używając GET. Wracanie działa
> tak, jak zawsze powinno.

Hmm.. ciekawe. Poeksperymentuję bo faktycznie nie pomyślałem o takim
podejściu. Mam jednakże pewną wątpliwość... a co jeśli naszą intencją jest
pozostanie na tej samej stronie? Przykładowo taki przypadek ma miejsce przy
aktualizacji ilości w koszyku albo akceptacji kryteriów w wyszukiwarce.

> To jest mniejwięcej to, co opisałeś na początku wątku. Sęk w tym, żeby to
> stosować tylko wtedy, gdy potrzeba POST (czyli nie przy wyszukiwaniu) i
> żeby URL podany w Location zawierał coś unikalnego zależnego od danych z
> POST, jeśli ma z nimi jakiś związek (jeśli wyświetlasz tylko stronę z
> "dziękujemy za wysłanie formularza", to nie musi być unikalny. Jeśli
> wyświetlasz "dodałeś czajnik do koszyka", to powinien być unikalny, żeby
> po dodaniu czegoś innego do koszyka użytkownik na pewno nie dostał strony
> o czajniku).

Tak, ja nawet dołączam ID transakcji - nie tylko jest wtedy unikalny lecz
nie pozwala na celowe powtórzenie operacji. Każdy moduł programowy CMS'a,
który przetwarza dane z formularzy bada zgodność ID transakcji z formularza
z poprzednio obowiązującym i dopiero wtedy traktuje dane jako
uwierzytelnione. Każde przeładowanie = nowy ID.

> Jeśli masz w aplikacji choć odrobinę abstrakcji, to powinno dać się używać
> GET na początku i bezboleśnie przerobić na POST, jeżeli ilość pól urośnie
> do niebezpiecznego rozmiaru.

Ja dmucham na zimne i POST stosuję wszędzie :-) Szczerze mówiąc tylko przy
wyszukiwarce widziałbym uzasadnienie stosowania GET ale to też obarczone
byłoby ryzykiem. Nie chciałem wdawać się w szczegóły lecz widzę, że
powinienem. Otóż w swoim CMSie udostępniam możliwość konfigurowania
wyszukiwarki z poziomu sekcji redakcyjnej. Właściciel sklepu / portalu /
prostej strony WWW sam decyduje jakie kryteria i w jakich wyszukiwarkach w
systemie mają być dostępne. Mało tego - sam określa jakie cechy posiada dany
dokument / produkt. Wszystkie z nich mogą stanowić kryteria wyszukiwania -
to kwestia kliknięcia tylko. Tak więc chcąc uniknąć niespodzianek związanych
z przekroczeniem długości GET - stosuję POST.

> W praktyce jednak z tym się nie spotykam. Formularz, który ma kilkaset pól
> albo opcji do zaznaczenia w <select> najczęściej jest też zbyt
> skomplikowany dla użytkowników i robi zbyt wiele rzeczy na raz. Taki
> formularz dzielę na mniejsze (coś a'la wizard) albo wybór spośród setek
> indywidualnych opcji zamieniam na coś innego - np. wybór całych
> grup/kategorii albo wg. tagów/słów kluczowych.

Takie wielopolowe formularze mają zastosowanie np. przy ręcznym
aktualizowaniu cen produktów. Wtedy dobrze jest wykorzystać listę produktów
i pól cenowych. Natomiast w wielu pozostałych przypadkach wystarczy jedno
pole aby przepełnić możliwości GET. Takim polem jest np. "treść wiadomości"
w formularzu kontaktowym lub "uwagi do zamówienia" w koszyku. Nie
ogranicznam ilości znaków bo nie powinienem.