On Thu, Nov 6, 2014 at 4:32 AM, Sanford Whiteman <figureone...@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
