mike wrote: > On 8/8/08, Per Jessen <per@xxxxxxxxxxxx> wrote: > >> Same as POST then :-) (except for the resume bit). >> >> I still don't see much of a difference. It doesn't matter much to >> me, >> I'd just like to understand what the real difference is. Maybe I >> need to go and read RFC2616. > > I'm all for using existing POST but it seems like a lot of > configuration needs to occur, Well, that's not really true unless your requirements for upload go beyond what is considered the norm/default. Large files for instance are not considered the norm, so yes, some additional configuration is necessary. > and PHP is expecting a single stream of data. If the stream is broken, > how do you resume it? If you accepted the data raw you could dump the > stream to a file until it ends, and then fseek($fp, $offset) when you > get a resume request... Yes, but that does seem to be the only point about PUT vs. POST. > PUT seems to be expected to be straight old "file $x goes here" ... I > actually am not allowing the file to be put on the filesystem directly > but fed to a PHP script. > > I am totally down for POST since POST is supported by browsers, flash, > everything, and PUT has some limitations (java applets aplenty, flash > can do it i think but you have to do actual raw socket communication > and I haven't found an applet for that yet) I am not for or against either, I'm just looking for the right argument for PUT support as it seems to be lacking (and I've never found myself in a situation where PUT was the solution). /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
