多部分邊界屬性中的反斜槓

當多部分邊界屬性中出現反斜槓時，預期的行爲是什麼？該RFC（第5.1.1節）不允許它，但是，阿帕奇似乎明白了這個請求：多部分邊界屬性中的反斜槓

POST/HTTP/1.1 
Host: myhost.com 
Content-Type: multipart/form-data; boundary="\foo" 
Content-Length: 74 

--\foo 
Content-Disposition: form-data; name="bar" 

baz 
--\foo--

對我來說，阿帕奇解釋的邊界應該是「富」，而不是「\富」爲反斜槓轉義'f'和後置變量「bar」不應該被設置。

來源

2016-04-21 Jeff Bencteux

你確實是對的，section 5.1.1中給出的語法在這裏不允許反斜槓。通過RFC 822, section 3.3，您也可以期待\f成爲f的引用字符串。

但是，在現實中，執行幾乎沒有執行任何超出\"→"的翻譯。由於很多客戶非常喜歡...什麼是和什麼不是有效的邊界，所以同齡人有一種傾向於非常原諒他們被餵食的東西，並且只是逐字逐句地接受邊界，這是我相信Apache是在這裏做。

所以，如果一切都嚴格按章辦事，預期的行爲在這裏是到：

讓阿帕奇把請求（爲便於討論，我們假設的Apache進行處理它本身，這是很少會與POST請求），
解析所述元數據，
發現該內容包括由\foo分隔的多個部分發生，
得出結論，在郵件正文中的分隔符必須是--foo<CR><LF>，
REALIZE說定界符實際上從未出現在體內，
產生400/Bad Request狀態碼作爲消息體似乎已損壞

來源

2016-04-21 14:39:58 DaSourcerer

我有一種感覺阿帕奇很寬容的，Nginx的不相同其實。我理解你的觀點，但這是一個令人驚訝的行爲，我真的不知道Apache是否想要它，或者它只是一個錯誤。不管怎麼說，多謝拉。 –

@JeffBencteux嗯，MIME是相當古老的，實現各不相同。我也懷疑大多數實現者不會仔細閱讀RFC，所以MIME解析器必須對他們的輸入相當自由。如果您有興趣，請閱讀[本博文]（http://jeffreystedfast.blogspot.com/2013/08/why-decoding-rfc2047-encoded-headers-is.html），瞭解解碼標題時遇到的挑戰，以及[this咆哮]（http://jeffreystedfast.blogspot.com/2013/09/time-for-rant-on-mime-parsers.html）解析器。 – DaSourcerer

多部分邊界屬性中的反斜槓

回答

相關問題