> Miałem na myśli walidację danych (czy pole przeznaczone na e-mail, nawet
> jak nazywa się dupa, zawiera coś przypominającego e-mail).

No i właśnie o tym również mówię. Jeśli nazwiesz pole email i dasz walidację
jako email to nawet najgłupszy robot spamowy wklepie tam email, który
przejdzie walidację.

> Jeśli przejmujesz się tak bardzo spamem, to pola na imie i nazwisko też
> można sprawdzać pod kątem spamu - nie słyszałem, żeby ktoś miał na
> nazwisko "http://...", a pewnie niejednego bota podkusi wpakowanie tam
> linku.

Wiesz... to już byłby przerost formy nad treścią - trzeba szukać złotego
środka.

> W przeglądarkach obsługujących HTTP poprawnie dostajesz poprzednią stronę
> bez pytania i bez ponownego POST :)

A jakie to? Pod IE i FF otrzymywałem zawsze zapytanie o zgodę na re-submit i
to było przyczyną mojej decyzji dot. zastosowania sztuczki z location. Być
może coś w bieżących wersjach zmienili...

> W tych, które mylą cache z historią musisz użyć sztuczki z POST + status
> 303, żeby się głupio nie pytały.

Poeksperymentuję i jeśli zadziała to zmienię choć nie bardzo rozumiem
róznicę pomięcy samym location a location + 303. Z punktu widzenia
użytkownika zachowanie aplikacji będzie identyczne w przypadku gdy location
prowadzi pod ten sam URL co formularz. Może w przypadku gdy submit ma
prowadzić do innej strony to wtedy warto 303 posłać aby powrót działał
"poprawnie" ? To miałeś na myśli?

> W przypadku koszyka możesz przekierować spowrotem na stronę koszyka, ale
> pod warunkiem, że strona koszyka jest niecache'owalna (nigdy nie wysyłasz
> jej bez Cache-Control: no-cache). Alternatywnie możesz przekierować na
> koszyk?wersja=123456

Już lepiej wyłączyć cache bo cholera wie w jaki sposób user powróci: czy
"wsteczem", czy linkiem w treści strony, czy z palca wpisze URL.

> Tak na marginesie - obsługujesz jakoś ładnie dwukrotne wysłanie
> formularza? (tzn. nie wielkim błędem, tylko pokazywaniem wyniku pierwszego
> wysłania?)

Tak. Wkurzały mnie błędy z tym związane no i przerobiłem CMS aby uniknąć
wszelkich konsekwencji podwójnego submitu.

> Problem może się zdarzyć jak ktoś dwukliknie submit albo sieć nawali zanim
> użytkownik dostanie odpowiedź na pierwsze wysłanie formularza i umyślnie
> wyśle go jeszcze raz. Jeśli po prostu odrzucasz użytą transakcję, to
> operacja wykona się pomyślnie (za pierwszym razem), ale użytkownik zobaczy
> błąd (zobaczy tylko drugi raz) i pomyśli, że się nie wykonała.

Jeśli sieć nawali no to nic nie zrobisz - cudów nie ma. Wtedy oczywiście
user zobaczy niedostępność URL itp.i może tworzyć w głowie różne
scenariusze - m.in. że submit nie doszedł do skutku. Jeśli natomiast kliknie
drugi raz bo za pierwszym mu nie zadziałało (bo albo faktycznie tak było
albo zadziałało lecz odpowiedź jeszcze nie nadeszła) to CMS zaakceptuje
jedynie pierwszego submita, który do niego dotarł a kolejne ze przetworzonym
już ID transakcji zignoruje.

W podtekscie pytasz jak to zrobiłem?
Banalnie... jądro systemu generuje wspólny ID dla nowych transakcji dla
wszystkich modułów programowych, które mają zastosowanie na danej stronie
WWW. Jeśli te moduły potrzebują formularzy HTML, to każdy z modułów ustawia
ukryte pole swojego formularza "id_transakcji_modulu_X". Po przeładowaniu
każdy z modułów sprawdza czy jego formularz zwraca wartość tego pola równą
poprzednio wygenerowanemu ID. Jeśli tak, to przetwarza formularz, jeśli
nie - to odtwarza tylko poprzednie wartości swojego formularza. Jedną z
ostanich operacji jest zapamiętanie przez jądro ID_old=ID. Amen.