Autor | Zpráva | ||
---|---|---|---|
Rfilip Profil |
Ahoj,
narazil jsem na menší ale zajímavý problém s nescepovanými mezerami v hodnotě GET proměných: příklad kod t.php: <?php var_dump($_GET); /t.php?a=A+B&b=C nebo /t.php?a=A%20B&b=C Výsledek: array(2) { ["a"]=> string(3) "A B" ["b"]=> string(1) "C" } Ale požadavek (nutno zkoušet napríklad programem telnet, tedy aby nedošlo k escapování prohlížečem) /t.php?a=A B&b=C Výsledek: array(1) { ["a"]=> string(1) "A" } Sice druhý požadavek porušuje specifikace HTTP ale přesto PHP nezvládne neescapovanou mezeru? |
||
Tori Profil |
To je AFAIK záležitost HTTP a identifikace jednotlivých částí hlavičky požadavku. Takže příčina nebude v PHP, ale už v serveru, který identifikuje mezeru jako konec požadované URI.
RFC-1945, kap. 5.1 - Request-Line: „The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by SP characters. No CR or LF are allowed except in the final CRLF sequence. Request-Line = Method SP Request-URI SP HTTP-Version CRLF “
Tamtéž v kapitole 3.2.1 - General Syntax je mezera (SP) označená jako "unsafe". RFC 1738, kap. 2.2 - URL Character Encoding Issues „Octets must be encoded if they have no corresponding graphic character within the US-ASCII coded character set, if the use of the corresponding character is unsafe, or if the corresponding character is reserved for some other interpretation within the particular URL scheme. [...] Unsafe: Characters can be unsafe for a number of reasons. The space character is unsafe because significant spaces may disappear and insignificant spaces may be introduced when URLs are transcribed or typeset or subjected to the treatment of word-processing programs.“ |
||
Rfilip Profil |
#3 · Zasláno: 21. 10. 2013, 22:15:25
Diky, do RFC se mne nenapadlo podivat, ale pokusama s php a apachem, jsem dospel k zaveru ze apache tu cast query stringu za mezerou zahodi/ignoruje a diky tobe vim prc.
|
||
Časová prodleva: 11 let
|
0