最近遇到一個神奇的bug，當通過路由query傳參跳轉到新的頁面時，新頁面請求接口的Request URL后面自動拼接上了query傳參 具體如下： 跳轉路由是這樣的 跳轉到新的頁面后新頁面所有請求接口的地址 默認請求接口的地址 ...

這種情況明明是post請求，但是在請求的url中拼接了參數 如果出現這種問題基本上是：axios.create使用自定義配置新建一個 axios 實例時進行post請求的時候用了params配置項。 1. params 會將請求的參數拼接到url中去，用於get請求 2. data ...

由於后台接收的參數格式為FormData格式， 在axios中參數格式默認為， 在傳參數前，將原先官方提供的格式 改為如下： 成功得到后台返回的數據 ...

今天有個post請求，還挺少見的。 這個post請求，直接在post請求地址后，加參數。如下： 加密前如上所示，用fiddler抓包。加密后的如下： 咨詢資料后，post 請求，在地址后加參數。 將data參數用params 接收即可。 用params ...

http0.9只有get請求，你看這樣多簡單，想發送什么數據，就把數據添加到url的后面， 很多人說安全性？安全影響什么了？數據暴露，即便是約定好的數據，寫在那里，你說不定也不明白參數的意義，倒是安全性並非是主要原因 什么？丑陋？拖着冗長的鏈接，看着倒是確實不舒服，那么到底是什么主要的原因 ...

...

HTTP請求中，如果是get請求，那么表單參數以name=value&name1=value1的形式附到url的后面，如果是post請求，那么表單參數是在請求體中，也是以name=value&name1=value1的形式在請求體中。通過chrome的開發者工具可以看到如下（這里是 ...

一.MINE TYPE問題： php對mime type為“application/x-www-form-urlencoded”（表單提交）和“multipart/form-data”（文件上傳）的Post請求的數據作特殊處理 下面以“multipart/form-data”為例對源碼進行解析 ...