Post Vars?

Rasmus wrote: > > I refuse to believe that even M$ is that stupid. Are they actually > > sending a form-urlencoded mime type and then not sending the data > > in that format? That's like specifying image/gif and sending a > > JPEG. You just don't do that. Absolutely. I wouldn't have believed it either. But seeing is believing. You'd think we'd be used to it by now, but it seems M$ are still capable of surprising us. FYI I've appended to the end of this message the start of the first block which IE5 sends when it exports favorites to the server. Rasmus wrote: > HTTP_RAW_POST_DATA is only set if PHP encounters an unrecognized > encoding type. Setting it for the regular form-urlencoded type > would be a waste of memory as you would then have two copies in > memory. And it is trivial to get the raw data from the decoded > data. Something like: > > $first=1; > while(list($k,$v)=each($HTTP_POST_VARS)) { > if($first) $data = urlencode($k) . '=' . urlencode($v); > else $data .= '&' . urlencode($k) . '=' . urlencode($v); > $first=0; > } > > Now $data would contain the original posted data string. It would if the original string was form data. But unfortunately this doesn't work when the string is an unencoded HTML file (e.g. an IE5 favorites post). 1. Several of the processes involved in 'decoding' the data are irreversable: For example, dot, space and underscore characters in the 'keys' are all converted to underscores. This 3 to 1 mapping is obviously irreversable. There is a similar problem with spaces and plus characters in the 'values'. 2. Most of the data is lost. I'm not sure why, but it's not surprising: PHP expects an alternating sequence of '=' and '&' characters separated by urlencoded data. But what it gets is an unencoded text file (including end of line characters) with many '=' and very few '&'. The data is also relatively long, IE5 sends my bookmarks in four blocks (including the header). This is obviously Microsoft's fault. But there are a hell of a lot of their browsers out there. If PHP is going to be able to accept IE favorite uploads (and who knows what else it labels 'application/x-www-form-urlencoded'), then it needs a workaround. Rasmus wrote that if posted data is not application/x-www-form-urlencoded: > PHP gives up trying to parse the data and just makes the raw data > available in $HTTP_RAW_POST_DATA. Perhaps PHP could also check the legality of the first character before attempting to parse the data? IE5 favorite uploads always start with '<' (Netscape format). But in application/x-www-form-urlencoded data, '<' should have been urlencoded, and 'keys' shouldn't start with '<' either. This illegal content would ensure the POST is made available in $HTTP_RAW_POST_DATA instead of being parsed. This is just one solution, but it does have the advantages of being consistent with the existing policy and always avoiding having two copies of the posted data in memory. Regards, Ian _______________________________________________________________________ POST http://www.menumarks.com/test.php HTTP/1.0 Content-Type: application/x-www-form-urlencoded User-Agent: PostFavorites Host: www.menumarks.com Content-Length: 42137 Proxy-Connection: Keep-Alive Pragma: no-cache Cookie: mmid=1240350077 <!DOCTYPE NETSCAPE-Bookmark-file-1> <!-- This is an automatically generated file. It will be read and overwritten. Do Not Edit! --> <TITLE>Bookmarks</TITLE> <H1>Bookmarks</H1> <DL><p> <DT><H3 FOLDED ADD_DATE="962809347">Links</H3> <DL><p> _______________________________________________________________________