Zitat von Hartmut Holzgraefe <[EMAIL PROTECTED]>: > My approach was to provide a php://input stream instead of the > $HTTP_RAW_POST_DATA > variable and additional cleanup code that would swallow any unread > content on > request shutdown. php://input provides the same flexibility as > $HTTP_RAW_POST_DATA, > without being limited for post requests. It can be safely enabled by > default > without creating any memory problems as content data is only passed thru > the > PHP engine without being stored internaly.
Do you mean, this is your plan or this already works? > The only execption is POST data that already got interpreted by a POST > content > type handler. As HTTP requests come in via sockets it is not possible to > just > rewind the stream pointer to the beginning of the content data after it > has > been read in and analyzed to populate the $_POST array. In this case it > either > has to be stored in a memory buffer just like $HTTP_RAW_POST_DATA always > did > or put into a temporary file. > With in-memory storage the complete multipart/form-data handler rewrite > would > be rendered useless as file upload forms would still be limited by memory > constraints. File storage on the other hand would lead to a serious > processing > overhead for small to average size POST requests generated by simple > forms > while wasting additional disk space for the majority of file uploads. > Another alternative for multipart/form-data would be to just store the > non-file parts in memory and read back (and MIME-encode) the uploaded > files > now stored in temporary disk files back on demand, so presenting the user > a reconstruction of the original input content. This approach would > preserve > resources by avoiding redundant storage of data but would also require > every > content handler that does not just maintain a in-memory copy of input > data > to provide an interface for data reconstruction. That makes the most sense to me though also sounds most complicated. ;-) > None of these approaches has yet been taken, instead raw data is just > simply > not provided for multipart/form-data requests since 4.2, and i don't see > a > way to fix this for 4.3 within a reasonable time frame. Still i think my So, I guess this answers my earlier question. > introduction of the php://input stream is a great inporvement over the > 'raw' > variable, especially with file PUT and WebDAV requests in mind. > > What definetly needs to be fixed is my complete missinterpretation of > $HTTP_RAW_POST_DATA itself and the always_populate_raw_post_data setting, > this will be done later today (but multipart/form-data POST requests will > still be ignored no matter what always_populate... is set to due to > memory > preservation reasons) If you're ready with your patches could please post a summary or table about what data ($_POST, $HTTP_RAW_POST_DATA, php://input) is available with what content type and what configuration? That'd be great. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
