我正在使用現有的Silverlight文件上傳器,它將文件分成多個塊並使用多個HTTP請求傳輸文件。使用POST方法在塊中發送文件時,是否使用適當的HTTP Content-Range標頭?
目前,它發送查詢字符串的開始和總字節信息,但作爲學習練習,我想使用更多的基於標準的方法。
我以前在實現提供內容的端點時使用了HTTP Content-Range標頭。在從客戶端向服務器發佈內容時,此標題是否也適用?
我正在使用現有的Silverlight文件上傳器,它將文件分成多個塊並使用多個HTTP請求傳輸文件。使用POST方法在塊中發送文件時,是否使用適當的HTTP Content-Range標頭?
目前,它發送查詢字符串的開始和總字節信息,但作爲學習練習,我想使用更多的基於標準的方法。
我以前在實現提供內容的端點時使用了HTTP Content-Range標頭。在從客戶端向服務器發佈內容時,此標題是否也適用?
是的。
RFC 2616 (HTTP 1.1), Section 14開始就指出:
對於實體頭字段,發送者和接收者指任 客戶端或服務器,這取決於誰發送和誰接收 實體。
除此之外,定義Content-Range標頭的Section 14.16似乎不包含任何限制其用於請求或響應的語言。
可能不是,至少截至2014年(原來的答案是2011年)。
更新HTTP 1.1規範,rfc7231 (4.3.3)說,對有效POST響應下列操作:
原始服務器通過選擇依賴於處理所述 POST請求的結果的 適當狀態代碼表示響應語義;幾乎所有由此 規範定義的狀態代碼都可能在POST響應中被接收到(例外 爲206(部分內容),304(未修改)和416(範圍不是 可滿足))。
鑑於此語言已明確添加到更新後的規範中,我懷疑作者是否打算將Content-Range
標頭與POST方法一起使用。
還有人可以使用範圍的標題上傳文件塊時?我在rfc中看不到任何關於這個的問題 – Toad
這就是最初的問題所在 - 我的結論是它是合適的,但你必須確保服務器支持它。如果您也在編寫服務器代碼,這不是問題,但我認爲許多服務器不太可能支持以這種方式分塊上傳。 –
這個問題涉及'內容範圍'。我指的是'範圍'。我自己製作的服務器,我需要某種分塊上傳機制。所以我想知道'範圍'是否會像'內容範圍'一樣好。規範'範圍'似乎指的是請求,'內容範圍'似乎指的是迴應。 – Toad