A brief analysis of the RFC1867 protocol format for "HTTP" alternative post header data

http://blog.csdn.net/ai2000ai/article/details/52161979

yesterday in the actual combat form simulation submission, there are found in the submission of a form, the page (discuz! Forum) error, unable to detect the data source and so on, but I did submit http_referer Ah, how can this happen? Asked the next haohappy, he gave a pear class, http/client, just found that I studied a few days of East, there is a ready to use, "using the pear stand on the shoulders of giants", this is not wrong. Try to assemble a client in a few days. Also pulled away, the book to the story, said to study a different post head, why say the alternative, because the general post head of the content-type:application/x-www-form-urlencoded and his is content-type: Multipart/form-data; boundary=-------7d71f4234700b8 So what's the difference between the two? 1, did the form HTML coder all know, in need to have the upload file operation, the form type must be Enctype= "Multipart/form-data", then here also for this reason, investigate its root, can trace back to RFC1867 agreement, This protocol is mainly based on the HTTP protocol to add the file attribute to the input tag, while qualifying the form must be post,enctype must be multipart/form-data. 2, the latter increased the boundary, so-called boundary is actually split line, RFC1867 use Boundary Segmentation HTTP Entity data. The numeric character area of the boundary is randomly generated. 3. Changes to HTTP Entities

Because RFC1867 adds the ability to upload files, the content of the uploaded files will naturally be added to the HTTP entity. Now because there are both http generic parameter entities and the entities that upload the files, each entity is segmented with boundary, and the HTTP entity looks like this:

-----------------------------7d71f4234700b8
Content-disposition:form-data; Name= "Formhash"


59329e15
-----------------------------7d71f4234700b8
Content-disposition:form-data; Name= "Isblog"




-----------------------------7d71f4234700b8
Content-disposition:form-data; Name= "FID"


104
-----------------------------7d71f4234700b8
Content-disposition:form-data; Name= "Subject"


Test
-----------------------------7d71f4234700b8
Content-disposition:form-data; Name= "iconID"


0
-----------------------------7d71f4234700b8
Content-disposition:form-data; Name= "Usesig"


1
-----------------------------7d71f4234700b8
Content-disposition:form-data; Name= "Message"


Test
-----------------------------7d71f4234700b8
Content-disposition:form-data; Name= "attachperm[]"


0
-----------------------------7d71f4234700b8
Content-disposition:form-data; Name= "attachdesc[]"




-----------------------------7d71f4234700b8
Content-disposition:form-data; Name= "attach[]"; Filename= ""
Content-type:application/octet-stream




-----------------------------7d71f4234700b8
Content-disposition:form-data; Name= "attachperm[]"


0
-----------------------------7d71f4234700b8
Content-disposition:form-data; Name= "attachdesc[]"




-----------------------------7d71f4234700b8
Content-disposition:form-data; Name= "attach[]"; Filename= ""
Content-type:application/octet-stream




-----------------------------7d71f4234700b8
Content-disposition:form-data; Name= "WYSIWYG"


1
-----------------------------7d71f4234700b8--

Obviously, with the addition of file uploads, the HTTP entity becomes slightly more complex, starting with boundary to separate the entities so that they can be read, and then the FileUpload format is limited.

4, then again, this format is also required to provide the Content-length attribute, then compared with the simple post data head, you can find that the change in the place:

......

Content-type:

......
Content-length:

......

Data body goes here~

After noticing the changes in these places, you can post it as usual.

A brief analysis of the RFC1867 protocol format for "HTTP" alternative post header data