As there is a platform project requirement, I went to the public platform interface and found that the ucrl command is required for uploading and downloading attachments on the platform. So I tried this command on Linux:
Curl-f @ 123. Image http ://.......
The server writes the attachment code by itself and submits all forms.
Later, I checked the information and found that calling the curl command in Java is still quite troublesome. If I don't want to upload an attachment, I 'd better simulate the client to upload it myself. Next, I wrote the code to simulate client upload in one day.
After the test, the server reports processing of multipart/form-data request failed. Stream ended unexpectedly.
F. Continue debugging. After several changes, Google found that many people suddenly closed the page, causing the file to be not uploaded, or the file is too large, therefore, the server reports an unexpected end of the stream. I thought, I used the code. It was close only after transmission. It was impossible, and the file was only a few K. I simply commented out the close test, which is still the same way. I suspected it was a problem with the server code. I wrote a simple upload page and tried it. Yes, there is no problem with the page and curl. Then the server code should be okay, continue to focus on the simulated code. I think it should be because our packets are incorrect. So I read the error and read the source code of the Apach package, it may be because the packet was not complete when the packet was transferred into the packet. Then I used Firefox debugging to check what is the difference between the HTTP request information and our simulation, at first, I really didn't see any problem. I printed it in the background to know that there were two line breaks missing. Mom, it's really depressing.
\ R \ n is missing before and after the end boundary.
Stream ended unexpectedly