Petr Ferschmann wrote: >> Nastavovat accept-charset na formu nema smysl, >> protoze prohlizece pouzivaji kodovani stranky >> s formularem. > Což je dle specifikací špatně :-) http://www.ietf.org/rfc/rfc3986.txt > > Non-ASCII characters must first be encoded according to UTF-8 [STD63], > and then each octet of the corresponding UTF-8 sequence must be > percent-encoded to be represented as URI characters.
Jenomze tohle RFC je z roku 2005. A prohlizece existovaly uz o dvanact let driv, takze se ridily nejdriv podle niceho, protoze RFC specifikujici URL (ted se mi nechce hledat cislo) o kodovani ne-ASCII znaku cudne mlci, a potom pragmaticky prijaly, ze rozumne je posilat to ve stejnem kodovani, ve kterem od serveru znaky dostaly. Ze potom vzniklo RFC narizujici pouzivat UTF-8 musely ignorovat, protoze jinak by porusily zpetnou kompatibilitu s miliony existujicich webovych aplikaci. > > Zde je definováno, že všechny znaky v URL musí být kódovány jako UTF-8. > Ale to všechny prohlížeče nedělají (žádný) > Když máte stránku v UTF-8 tak se tento problém neprojeví. Pokud tedy > použijete jednoduchý POST, data jsou kódována jako GET a tím pádem můžou > být kódovány špatně. > > Když ovšem použijete enctype="multipart/form-data", řeknete, aby se data > neposílala v URL, ale jako příloha HTTP požadavku, > kde už je kódování uvedeno. To nejak michate dohromady vic veci. Tim jednoduchym POSTem asi myslite, ze data od prohlizece jsou MIME typu "application/x-www-form-urlencoded", coz je ten normalni zpusob ze data jdou sice v tele, ale jsou zapsana jako v URL, tj. "pepa=1&karel=2&lojza=3". Kdyz pouzijete atribut enctype na formu a zmenite MIME typ na "multipart/form-data", tak muzete poslat zaroven par binarnich souboru, ale data z formulare jdou v dost zbesilem tvaru, v podstate kazdy udaj jde jako samostatny soubor. O tomhle mam overeno, ze to spousta prohlizecu nedokaze poslat korektne. Proto neni dobry napad posilat se souborem i nejaka dalsi data. Kazdopadne pri POSTu typem ...urlencoded neni v typu obsazeno kodovani, protoze tam neni misto na "charset=utf-8". Takze server proste z principu nikdy nemuze vedet, v jakem kodovani mu data prichazi, a je jedno, jestli jsou v URL nebo v tele POST requestu. To ze vubec aplikace funguji je tim, ze prohlizece posilaji data v kodovani stranky s formularem, a tu obvykle posilala ta stejna aplikace, takze aplikace muze snadno spravne kodovani "uhodnout", i kdyz se ho od prohlizece nikdy nedozvi. > >> Takze v konfiguraci konektoru v server.xml se musi pridat atribut >> useBodyEncodingForURI="true". > Nebo uvedete URIEncoding. Myslím, že rozdíl je v tom, že v jednom případě to > uvedete explicitně, > ve druhém necháte tomcat převzít typ kódování z těla (takže jej můžete mít > proměnný). Ano, tak to je. Je lepsi prebirat kodovani z tela, pak si muze kazda webaplikace pouzivat jine kodovani. > BTW: jak to řeší, když hlavičky se parsují před tím, než se odesílá odpověď? HTTP hlavicky maji stejne jako URI povolene pouze ASCII znaky. Takze hlavicky se v klidu rozparsuji. A teprve pri prvnim volani request.getParameter() se zjisti nastavene kodovani requestu, pokud neni nastavene, pouzije se iso-8859-1, a parametry z URL i z tela POSTu se rozparsuji. > URIEncoding je doporučené řešení na > http://tomcat.apache.org/faq/connectors.html Ze je neco v dokumentaci jeste neznamena, ze to neni spatne :-) Makub -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Supercomputing Center Brno Martin Kuba Institute of Computer Science email: [EMAIL PROTECTED] Masaryk University http://www.ics.muni.cz/~makub/ Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775 --------------------------------------------------------------
smime.p7s
Description: S/MIME Cryptographic Signature
