The edge

Recently, a colleague of the project team, Xiao Ming, said that he could not upload the file/picture to the server. According to the feedback from his colleagues in the background, he did not receive the corresponding file field, so we could not determine whether you uploaded the file or not.

At this time xiao Ming refused to accept, the quarrel began. The Android team xiaoming thought that this was an interface problem, and the backend colleague told Xiaoming that it was his pot and needed to add the identification file, otherwise it could not be processed. Xiaoming is not happy, obviously oneself try to go up to spread the server of other people’s home to all use, to you this is not line, with what is my pot?

Although very unhappy, but under the pressure of life, Xiaoming compromise, to find the reason, after some negotiation, Xiaoming found that the project added a library, library upload file part of the code is actually used volley network request framework package MultipartRequest, (this year who still use Volley ah) very soon, With his rich experience, Ming identified the problem. The packaged MultipartRequest did not add content-Disposition, Content-Type, etc., which would have been a problem. Soon he added the following code to the Request, overriding getHeader(); Heart secretly happy, easy to solve.

Run, again cannot upload file smoothly. This makes Xiao Ming very distressed, how not to follow the routine? Let me see…

About Network Request

Network request content involves a lot, here, only for the group encountered this problem to discuss the corresponding network request part, that is, request message and response message. This paper also discusses only the network request message and response message of POST form. If you are not familiar with the content-Type and content-position mentioned in this article, you can refer to the following article, which also introduces other parts of THE Http web request in detail.

HTTP

Content-Type

The request message

In short, the composition of the request message: request line + request header + request body

Let’s take a look at a web request log that uses OkHttp to upload images (of course, the format is not exactly the same as the standard HTTP web request format, but basically the same content) to see what the data log looks like when the request is made.

The log analysis above shows that the request body of a POST form is divided into parts and parts by a content defined by: boundary. This is the format displayed during file uploading. That is, each field/file is divided into separate sections of your boundary. Content-type :multipart/form-data is specified in the first line of the request header. The data submission that identifies this request body is multipart/form-data, and there are two other common request body forms:

When Posting JSON data, you usually need to parse it yourself.

Application/X-www-form-urlencoded, which is the most common way to submit data. Multiple key-value pairs are joined by &. Only ASCII characters can be used. Non-ascii characters must be encoded by URLEncode.

  • The request line

    In the request line, you can see that the first is the request method, usually we only use GET and POST, other less commonly used include: PUT, DELETE, HEAD, TRACE, CONNECT, PATCH. This is followed by the corresponding request URL. In the OkHttp log output, we can see that there are only two request lines. In the request line, the requested URL is followed by the protocol name and version number: HTTP/1.1. It’s possible that the formatted output didn’t add this.

  • Request header

    The HTTP header contains attributes in the format of key:value. The server obtains the configuration information of the client based on these key-values.

  • Request body

    If a request contains form data, this is also an important part of the process when we upload a file request. Content-disposition and Content-Type were just added to the request Header. We did data validation on this part in the background, so we could not get the uploaded file correctly.

About the Content – Disposition

Content-disposition is an extension of the MIME protocol that instructs the MIME user agent how to display attached files.

  • (1) As the header in the message body

    In HTTP scenarios, the first parameter is either inline (the default, which indicates that the message in the reply will be displayed as part of the page or as the entire page) or attachment (which means that the message body should be downloaded locally; Most browsers will present a "save as" dialog box, prefilling the value of filename with the downloaded filename, if it exists).Copy the code

    Such as: the Content – Disposition: attachment; Filename =”filename.jpg”, in which case the web page or attachment in the web page triggers the “Save as” dialog box.

  • (2) as the header in the multipart body

    The common ones are as follows:

    Content-Disposition: form-data
Content-Disposition: form-data; name="fieldName"
Content-Disposition: form-data; name="fieldName"; filename="filename.jpg"

Copy the code

Seeing this, I think we have been very clear, above xiao Ming’s case should be how to modify. After understanding this, Ming finally created a file upload request inherited from Volley’s Request, overwrote getBody, and added content-Disposition and Content-Type descriptions to fields/files by concatenating them. For the part used in this project, the main added code is as follows :(non-okhttp operations, OkHttp and Retrofit operations are easier, you can refer to them elsewhere if necessary)

The response message

Response messages are also mentioned here in passing. Response message composition: response line + response header + response body

Here is another example of a response: a log printed by OKHttp is a bit different from the standard format, but the general structure is the same.

Here’s a rough description:

Response line Response header Blank line response bodyCopy the code

  • Response line

    The status line consists of the HTTP version field, the status code, and the description of the status code. They are separated by Spaces. 200 OK indicates the status code + description. A standard format would be: HTTP/1.1 200 OK

  • Response headers

    Header field name: value + carriage return + line feed

  • Response body

    The JSON string above is the body of the response

conclusion

In the case of a network request to upload a file, the key to distinguishing whether the Content of the POST field is treated as a file is whether content-disposition contains filename. Because there are different types of files, content-Type is also used to indicate the Type of file. If the Type is unknown, the value can be application/octet-stream to indicate that the file is a binary file. If the file is not a file, the content-type can be omitted.

So far, this case has been analyzed, because the Http part involves too much content, only discuss the content involved in the file upload part, if there is improper, but also hope that you point out the advice, will be corrected. Thank you!