今天工作的時(shí)候遇到一個(gè)坑，在客戶端用nodejs給服務(wù)器發(fā)送HTTP請求，服務(wù)器老是報(bào)錯(cuò)：In the context of Data Services an unknown internal server error occurred

經(jīng)過服務(wù)器端調(diào)試發(fā)現(xiàn)，服務(wù)器根本就沒有正確解析出這個(gè)請求的content-type。在postman里能工作的場景下，正確解析出的content-type是multipart/mixed：

而我的nodejs代碼里明明指定了這個(gè)content-type的啊？

經(jīng)過一行行代碼分析，最后發(fā)現(xiàn)問題出在第63行的json字段的值。我錯(cuò)誤的賦成了true。

這個(gè)參數(shù)起什么作用？調(diào)試一下就知道了。如果為true，進(jìn)入第403行。

如果請求內(nèi)部有entity的content-type不是application/x-www-form-urlencoded, 則進(jìn)入第1293行。

safeStringify的實(shí)現(xiàn)邏輯就是瀏覽器原生的JSON.stringify, 把應(yīng)用程序傳入的json對象序列化成字符串。但是我的代碼里，傳入request module的請求體是一個(gè)字符串，而json參數(shù)設(shè)的又是true，所以邏輯上就不對了。把這個(gè)json參數(shù)的值改為false后，一切正常。

要獲取更多Jerry的原創(chuàng)文章，請關(guān)注公眾號"汪子熙":

總結(jié)

以上是生活随笔為你收集整理的nodejs request module里的json参数的一个坑的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。