Hi! > makes user land code more readily equipped to enable the user to do that > handling. In the same way that it does for POST. This creates some more
Well, for POST PHP actually parses the data - url encoding, form encoding, files, etc. - and puts it into the data structure. For generic REST case, it'd be harder to do the same because there are too many options of how the data could arrive. > For this to be possible in a more generic sense this would mean that PHP > only relies on the Content-encoding and Content-type headers to > determine how to decode the payload and parse its contents into super > global variables such as $_POST and $_FILES. This is currently what > PHP's SAPI implementation already does. The changes required to make Currently, it supports only basic form encodings. But if we get into handling all application types, it's a huge can of worms to have in core. > If the Content-type is applicatoin/json, for example, instead of the > normal application/x-www-form-urlencoded, PHP would simply parse the > enclosed entity body as JSON rather than urldecode it. If the That's not as easy as you think. Even JSON can have different encodings, be parsed in different way (json_decode right now has three options, and could have more in the future) an so on. But that's only JSON - why would then we single out JSON and not support XML or YAML or iCalendar or any other 1001 formats? > multipart/form-data MIME in the same way that post does, so encoding > can't vary. If the Content-type header is application/binary, for > example, we can simply make the file available in $_FILES or just leave There's no application/binary in standard MIME, ITYM application/octet-stream, but files do not have to be octet-stream, they can be of any type. And when you get the data, you in general don't know if it is meant to be a file or field or something else - that's on the app to decide. In the specific multipart/form-data case, we have content-disposition which tells us it was a file upload, but if it's not that format, all bets are off. In fact, nothing prevents a client from sending a file contents but the server treating it as a regular data field. > Here, I'm just proposing that PHP take on the addition of PUT handling > in a similar fashion that it does for POST, but only in the even that The problem is that while POST is used for forms (not only, but frequenly especially in webform context), PUT can be used for anything. We could of course make the core to identify PUT with mulitpart/form-data and parse it in the POST manner, I don't see any technical reason preventing that, but I think if you're already doing generic REST, then you'd be better served by generic parsing library (or a set of them) than by selecting one use case. I could be wrong of course, if PUT+mulitpart/form-data is a frequent use case and I just am not aware of it, then it makes sense to make RFC to add handling of it. So the question here is how common is the case of PUT+mulitpart/form-data? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
