Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78802 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 14340 invoked from network); 6 Nov 2014 09:32:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Nov 2014 09:32:15 -0000 Authentication-Results: pb1.pair.com smtp.mail=figureonecpr@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=figureonecpr@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.42 as permitted sender) X-PHP-List-Original-Sender: figureonecpr@gmail.com X-Host-Fingerprint: 74.125.82.42 mail-wg0-f42.google.com Received: from [74.125.82.42] ([74.125.82.42:57758] helo=mail-wg0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 91/EF-28384-E104B545 for ; Thu, 06 Nov 2014 04:32:14 -0500 Received: by mail-wg0-f42.google.com with SMTP id k14so700898wgh.1 for ; Thu, 06 Nov 2014 01:32:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9jDH725dOjByMlTkN21vHGX3M5u37yJuJXmqiOk7KEY=; b=IxDtugYcBF/tKgus/2/bi1Rg87voYTkbxXeKV2t5OQvHLhyz9Zn9OO1zPxF5uT/yIq T5hWnSwlWDZIluC0BZDl4l8QQHnmodmmH2s0qv2tG0/J54KuvtVzSzszDH0qQPbfay2f tZsbmxmmzuR49mrNr4R6tGt0k7opwpGiNHQc4/djMOxjIqtHZCh/hxolPRVYKWwITisl YQo+22r/YyY56Nz990z9504qj3cMLSNflSYsXJxkD68dYjzJodBPU4qIMEzHgymqcQYa +3jNEBBo7BgD/mxTUHNaPArIlx+wf0Ev53c7a+3IZuZL7xXY5drTrVzPhD51ZPJqw88Z 60Ow== MIME-Version: 1.0 X-Received: by 10.194.143.7 with SMTP id sa7mr3802360wjb.110.1415266331251; Thu, 06 Nov 2014 01:32:11 -0800 (PST) Received: by 10.216.194.132 with HTTP; Thu, 6 Nov 2014 01:32:11 -0800 (PST) In-Reply-To: References: <1DDB6E05-3143-4A74-8B13-AF85222579BA@ajf.me> <468730E8-4C38-49A3-A61A-59E107313D79@ajf.me> <9FB8B541-A040-4C0E-8884-A1EA06B3C266@php.net> Date: Thu, 6 Nov 2014 04:32:11 -0500 Message-ID: To: Sherif Ramadan Cc: Will Fitch , Andrea Faulds , Patrick ALLAERT , PHP Internals Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] New Standardized HTTP Interface From: figureonecpr@gmail.com (Sanford Whiteman) > Specifically, parsing the form data and populating it somewhere accessible > to the user as it is today in $_POST and making any binary upload available > in $_FILES or some other fashion. Ideally, making handling PUT more > consistent with the way PHP handles POST. OK, the first definition: "handling" means parsing multipart/form-data automatically into form field names and values. And again there are specific documents that expect this to be done for POST (and understandably so) but no such documents for PUT. Which means you want PUT to act as if it were as formally defined as POST. Which is where we started from: you are transplanting a standard from one method to the other. This doesn't mean you are violating an extant standard, it just is very, very far from compelling. And your best justifications for a present-tense need were wontfixes submitted by relative newbies. > First of all, RFC 1867 is not a standard. It's an experimental protocol > definition. Oh nonsense. You know very well that RFC 1867 conformance is an industry standard for file uploading When 2388 says "originally set out in [RFC1867] and subsequently incorporated into [HTML40]" it is not treating 1867 as some fringe document. Non-HTML uploaders (Flash/Java/Silverlight/cURL/all of them) use RFC 1867 as their design spec, not as some wacky experiment. http://lmgtfy.com/?q=rfc+1867+file+upload+support > No where in the internet standards tracking documents do I see a > definition that restricts multipart/form-data to POST. You're deliberately phrasing it backwards. The documents re: POST enshrine multipart/form-data as one of two encodings. There are no documents re: PUT that refer to form encoding. And I never said there was a restriction; in fact I specifically outlined how 2388 breaks all restrictions on multipart/form-data. However "no restriction" !== "an automatic connection." > I think what you're > referring to is the fact that the client UAs typically only ever handle form > data as multipart/form-data mime as POST-specific requests. This is of > course tied to the fact that client UAs don't typically follow the same > intents of a RESTful API client/server relationship. Allow me to re-iterate > the fact that this is one of the primary focuses of this discussion. That > people normally want to deal with PUT requests in PHP under the umbrella of > building their own RESTful APIs. Show me the RESTful justification for decomposing PUT requests *automatically*. There is none. There may be local knowledge that justifies decomposing PUT requests as if they are POST-like but it is not RESTful. I've read all the REST cookbooks there are. You're trying to make this a thing, and it's not. > It's the same thing as with a POST request today in PHP. Nothing is stopping > anyone from sending a you 2 GB multipart/form-data POST request either. Stop moving the damn goalposts and stay on topic. We are talking about a ***PUT*** today in PHP. Right now, that doesn't cost me anything. In your model it can cost me a lot. We have plenty of ways of warding off oversize requests depending on method. > should be checking intent before dealing with $_POST from the $_SERVER['REQUEST_METHOD'] anyway, since you can't relay on $_POST > necessarily being indicative of the request method anyway. Certainly with your new feature one would be ill-advised to assume that anything is what it seems.