> PUT is not intended to necessarily store the request entity body on the file > system. Its intention is to store the entity body at the request URI.
I never said it was. I used the expression "store at the URI" about 10 ten times on this topic. You are arguing in bad faith by putting words in my mouth. Stop. In a barebones implementation with just an HTTPd, PUT does mean the filesystem, which gives an easy example of how incredibly semantically different it is from POST. Most people do not understand the concept unless you give them a simple example. > So this unfounded claim that decomposition should not happen within PHP at > the request level, isn't a justification for prohibiting PHP from decomposing > the body. I made no such claim. I maintain that decomposition not be *required to happen* within PHP. I couldn't care less if you make it optional and don't use the $_POST superglobal. I've said this over and over. Expose the core MIME parser to the user. That'll make it easily used by frameworks, or via auto_prepend_file. Do not do it automatically for all requests. > For example, if the Content-type designated in the request indicates > application/binary it is safe to say that PHP should not attempt to > disassemble the input stream beyond applying > the decoding from the > Content-encoding header (which may actually happen at the web server level). > However, in this event it would make it a lot more convenient for the client > if the > entity is stored in $_FILES where its access is still more > manageable through the receiving code. I noted this case in the other thread and let it be laughed off, but I actually believe that this is a relatively sensible option, since it doesn't require any decoding. For that matter, I ninety-percent-kiddingly wondered if an application/tar body could be decomposed and its constituent files put into $_FILES, since that's a case we actually use daily. Again under user control, and not for every request to a given PHP install, but a kind of pre-superglobal API would be cool. Of course I know it'll never happen and I'm fine with that. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
