Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78804
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAA8DMBsr6WufUAyQXVw-C75_SxcPa6fWEKP6tESmBqT-JcwszQ@mail.gmail.com>
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com>
	<CACwt+JcYMS=+3t3e_JLHbNx-mgxUceiPOws2GZn9_QZ4HEo4Uw@mail.gmail.com>
	<CAL+t6cHDLHjTE3JK0md=KZ=AnRns6iYxfphzA3qnShermVeOmg@mail.gmail.com>
	<1DDB6E05-3143-4A74-8B13-AF85222579BA@ajf.me>
	<CAL+t6cH92NgWnr-0gh9AfTxX_1r5Fd0=+M6SeZu53BT3nPHSEg@mail.gmail.com>
	<468730E8-4C38-49A3-A61A-59E107313D79@ajf.me>
	<CAL+t6cGPiqZXx2rQCzSV-PCzAAJtMWi6xteCU0GB0XjsB4wSpA@mail.gmail.com>
	<CC2E198C-1B05-4329-B13D-47787EBE9FFC@php.net>
	<CAL+t6cESCv6s2AHGubuJ+vK26wpq0Uzn39JBLy+vZD8SNskqXw@mail.gmail.com>
	<9FB8B541-A040-4C0E-8884-A1EA06B3C266@php.net>
	<CAL+t6cGmEonNk0=Dkmih2G96WrXFDrcsn376eN0RjuuWWGPv4g@mail.gmail.com>
	<CAA8DMBvwf_8EOD7cFYbBggAQqEUy_rR6uYApd7Sse4f-ArNUOQ@mail.gmail.com>
	<CAL+t6cEVQaivZXENJuE7+BjgqPU0j4m4k-WJVzF=Xsbp4amciw@mail.gmail.com>
	<CAA8DMBsr6WufUAyQXVw-C75_SxcPa6fWEKP6tESmBqT-JcwszQ@mail.gmail.com>
Date: Thu, 6 Nov 2014 05:57:21 -0500
Message-ID: <CAL+t6cHSpzvWaLrPT-fiEiRJhwYyBacHUgdB+cu5JXNBhfDDVw@mail.gmail.com>
To: Sanford Whiteman <figureonecpr@gmail.com>
Cc: Will Fitch <willfitch@php.net>, Andrea Faulds <ajf@ajf.me>, 
	Patrick ALLAERT <patrickallaert@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d043c7f728e905a05072e8f03
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: theanomaly.is@gmail.com (Sherif Ramadan)

--f46d043c7f728e905a05072e8f03
Content-Type: text/plain; charset=UTF-8

On Thu, Nov 6, 2014 at 4:32 AM, Sanford Whiteman <figureonecpr@gmail.com>
wrote:

>
>
> > 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


I know that RFC 1867 clearly states it is not a standard.

"This memo defines an Experimental Protocol for the Internet community.
This memo does not specify an Internet standard of any kind." [1]

Also, you seem to be quoting out of context with the intention that the
reader will not try to seek out said context and simply assume your
supporting argument is sound and well-rounded. It is not. The standard you
are referring to [RFC 2388] only mentions the non-standard [RFC 1867] in
its introduction to state where the definition of multipart form data was
derived in these applications. This does not constitute RFC 1867 as a
standard.

Yes, HTML form data is where the need for multipart form data was
originally derived. As we know, client UAs implementing forms typically
either restrict the method to either GET, or in the case of constructing
multipart/form-data MIME, POST. However, as you mentioned, it has since
spread to be implemented in many other applications (outside of the scope
of HTML) such as in the case of FDFs.

I understand all of this and I get why you're making a strong connection
between POST and multipart/form-data mime. The part I'm not getting is why
you believe a multipart/form-data mime cannot be sent along with a PUT
request. The two things are independent of one another as I see it. One is
a media type header and describes the enclosed entity type (i.e.
multipart/form-data or application/x-json or whatever the content type may
be) and the other is an intent of request verb that describes the user's
intention in making the request (i.e. POST/PUT).


[1] https://www.ietf.org/rfc/rfc2388.txt

--f46d043c7f728e905a05072e8f03--