This is starting to get super ugly indeed... I was hoping I wouldn't have to essentially write an HTTP daemon from scratch, so I'll keep the sockets in mind as a *last* resort. As much as it would simplify things if $HTTP_RAW_POST_DATA (and friends) was fixed to always contain the data regardless of the Content-Type header used, it's going to take a long time before that fix trickles down into other people's PHP installations. Not everyone runs the latest versions, and this particular script I'm working on is being designed to be widely portable. *sigh* I started experimenting today with the idea of reconstructing a POST body from the $_POST[] and $_FILES[] arrays. It's doable, but with limitations. Form field names must not be permitted to contain periods, spaces, or opening square brackets. Those all get converted to underscores before the keys are created to the $_POST[] array, with no way to determine the original name. And if the form field name has both opening and closing square brackets respectively, weird funky sub-arraying occurs. Anyhow, I'd also need to do a workaround to this form field naming limitation, because server-side form-based image maps send the coordinates as formfieldname.x and formfieldname.y, no exceptions. So I'd have to search for any array key pairs that have identical names save for a _x and _y ending, and change the underscore back to a period. Of course this could mess up other form fields that just happen to end in _x and _y as specified in the HTML form, so I'd have to try several combinations (one each found key pair at a time + one for no changes) and keep comparing the hashes until I've found the correct POST body reconstruction. Then there's the final challenge: figuring out the order in which the form-data blocks were arranged in the original multipart body! It turns out the order of the $_POST[] array elements are created in the same order as the respective form-data parts in the original POST request, but if the form contains a file upload, it throws a wrench in the operation. The trouble is the $_POST[] array does not contain any elements for the file upload, so it's anyone's guess as to where in the multipart POST body the uploaded file data was inserted. The only solution I can think of is to try all the possible combinations until the correct hash is found. But if the form has several fields and multiple file uploads, this could take quite a long time... But hey, is this any dirtier than writing an entire middle-ware HTTP server in PHP? ;-) Richard Lynch wrote:
One possibly super ugly hack... You could maybe write your own middle-ware HTTP server thingie with some kinda socket functions, do what you want with the input, and then pass it on to PHP somehow... I think you might maybe be better off putting in a Feature Request to get RAW_HTTP_POST_HEADERS or whatever it is turned "on" for multipart/form-data, or even declaring it a Bug. It might just get labeled bogus as a bug though... You may even have some luck looking at PHP source to try to submit a patch for it... Doesn't seem like it would be THAT hard to do, once you find the dang lines of C code that do file upload, and the other lines that do the RAW_HTTP thing... 'Course, it would take me months just to find those lines of code, knowing me. :-v
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
