Forgive me for being a headline party, but in fact this pit has little to do with fetchIt boils down to sending http responses, gossip, and get straight to things. In order to have fun, I replaced vue-resource with the native JS fetch API in my own practice project, and the use effect is still excellent, and there is no obscurity like other native APIs.
In the previous article, fetch has been in the door, so this is only the point, when I used vue-resource and fetch before, I suffered a lot of losses in the conten-type setting, so I did a lot of homework, and the important thing was said three times, post request content-type, that is, the main way to set the format of the data request: application x-www-form-urlencoded (Most requests are available :eg:.)'name=denzel&age=18'Multipart form-data (file upload, this time the focus is on) application json (json format object, eg:) text xml (now used very little, send xml format files or streams, webservice requests are used more) I want to upload a ** to the server asynchronously through fetch to save it, and then return the response address of the service (the requirement is very simple, there is none). So I wrote **:
let data =new formdata();data.append('file',$("#realfile").files[0]);data.append('name','denzel'),data.append('flag','test')const option = , body:data};fetch('http://localhost:8089/analyse/imguploadservlet',option) .then(function(response)else })then(function(data))But what is printed on the server is an error message like this (fortunately the backend uses try-catch, otherwise it will pop up a lot of errors and you won't be able to find you):
Error message: The request was rejected because no multipart boundary was
found is very nonsensical, there is no backend**Before getting the data,The content-type of the request has been checked,And there is no error,That means that it is a request for file uploading,No problem,And the backend of this upload file**,I have used it in the jsp page before,No problem,Then check the request in Google dev-tools:
if (!servletfileupload.ismultipartcontent(request))dev-tools request information:
access-control-allow-methods:post, get, options, delete access-control-allow-origin:* content-length:0 content-type:text/html;charset=utf-8 date:sun, 16 jul 2017 01:51:51 gmt server:apache-coyote/1.1 request headers view source accept:*/* accept-encoding:gzip, deflate, br accept-language:zh-cn,zh;q=0.8,en;q=0.6 connection:keep-alive content-length:68172 content-type:multipart/form-data host:localhost:8089 origin:http://localhost referer:http://localhost/ user-agent:mozilla/5.0 (windows nt 6.1; wow64) applewebkit/537.36 (khtml, like gecko) chrome/59.0.3071.115 safari/537.36 request payload --webkitformboundaryj0rfrwvz56lnpj1u content-disposition: form-data; name="file"; filename="chn.png" content-type: image/png --webkitformboundaryj0rfrwvz56lnpj1u content-disposition: form-data; name="name" denzel --webkitformboundaryj0rfrwvz56lnpj1u content-disposition: form-data; name="flag" test --webkitformboundaryj0rfrwvz56lnpj1u--It turns out that I am not alone in encountering such a problem, everyone quotes such a sentence:
you should never set that header yourself. we set the header properly with the boundary. if you set that header, we won't and your server won't know what boundary to expect (since it is added to the header). remove your custom content-type header and you'll be fine.
Translated:
You shouldn't set the request header yourself (what ?).We'll set the boundaries correctly for the request headers, but if you do, neither we nor your server will know what your boundaries are (since the boundaries are automatically added to the request headers), remove your custom content-type request header settings, and the problem will be solved (translation scum, although English level 6 floated by, but that was six years ago).
Okay, knowing what the problem is, delete the content-type of the request header, and then send, oh my god, it's really yes, how can this be, doesn't it mean that every http request should correctly set its own request data type?Did I read my previous book in vain, ah, calm down, what others said was correct, then check the request information through dev-tools.
accept:*/* accept-encoding:gzip, deflate, br accept-language:zh-cn,zh;q=0.8,en;q=0.6 connection:keep-alive content-length:88623 content-type:multipart/form-data; boundary=---webkitformboundaryanydwsq1ajkugocd host:localhost:8089 origin:http://localhost referer:http://localhost/ user-agent:mozilla/5.0 (windows nt 6.1; wow64) applewebkit/537.36 (khtml, like gecko) chrome/59.0.3071.115 safari/537.36 request payload --webkitformboundaryanydwsq1ajkugocd content-disposition: form-data; name="file"; filename="screenshot_2017-05-23-11-41-22-090_com.wacai365.png" content-type: image/png --webkitformboundaryanydwsq1ajkugocd content-disposition: form-data; name="name" denzel --webkitformboundaryanydwsq1ajkugocd content-disposition: form-data; name="flag" test --webkitformboundaryanydwsq1ajkugocd--I've come to the conclusion that it's to be set up correctly. When fetch sends a request for the POST character, when the file is not uploaded, it doesn't matter if the data format you send is application x-www-form-urlencoded or application json format data, you don't set the request header, fetch will add a content-type = text xml type request header to you by default, some third-party jax You can identify the data you send and convert it yourself, but feth definitely doesn't, no, you can give it a try;When a file upload request is made, we don't know how the boundary is defined, so as suggested, we don't set the content-type. If the description in this article is incorrect, please correct it and discuss it together, after all, your knowledge is limited.