適當的Http狀態代碼用於在休息終點上上傳文件

我們正在開發一個應用程序，允許用戶在休息終點上傳文件。
可能有人請指導是否正確發送400錯誤代碼下面的驗證方案的失敗：適當的Http狀態代碼用於在休息終點上上傳文件

1) The Length of file name exceeds permissible limit. 
2) File name contains special characters 
3) Uploaded file was empty 
4) The System failed to read the uploaded file from disk.

問候，塔倫

來源

2017-01-06 Tarun

文件名的長度超過允許的極限。

我認爲400是不合適的，因爲在這種情況下請求的語法是正確的。在這種情況下，422 Unprocessable Entity更好。

文件名中包含特殊字符

非法字符意味着語法被打破了。所以400 Bad Request在這種情況下是一個適當的迴應。有人可能會聲稱需要定義非法字符，以便服務器可以權威性地發送400。

上傳的文件是空的

我想是因爲一個空文件是一個法律文件，它是不是一個錯誤。

系統無法從磁盤讀取上傳的文件。

請問系統是指服務器？然後，服務器應返回5xx響應，因爲它不是客戶端故障。如果發生一般讀取錯誤，服務器應返回500。

編輯：

上傳的文件是空的。

當應用程序語義禁止空文件時，400或422恰當。關於它們的更多細節在400 vs 422 response to POST of data

來源

2017-01-06 11:45:15

謝謝。根據我的應用程序邏輯，上傳空文件是不合法的。在這種情況下，我們應該向客戶發送什麼錯誤。 – Tarun

如果發現上傳的文件爲空 – Tarun

或許對於第3點使用406或411，發送ConflictHttpException是否正確，因爲它有點接近太空文件：https：//en.wikipedia.org/wiki/List_of_HTTP_status_codes但是，那只有當你想要捕獲一個空文件時 – KevinTheGreat

4xx狀態用於客戶端錯誤，5xx用於服務器端錯誤。所以，一般你需要4xx代碼來處理1）到3），而4）應該是5xx錯誤。

首先說一下你的情況4），一個簡單的HTTP 500似乎是合適的。如果你想表明客戶端可以稍後再試，HTTP 503會更合適。

現在爲1）至3）：根據RFC 2616，HTTP 400 indicates syntax errors;這通常是協議錯誤，例如無效的標題。但是，在這個通用的RFC中並沒有真正定義語義或有效負載錯誤（如Zaboj mentions），WebDAV提供了HTTP 422，這看起來很合適，但它並不真正用於通用HTTP。

最後，發送哪些特定的代碼並不重要。如果上傳失敗時使用HTTP 400或422，則無論是哪種情況，客戶端都將執行一些錯誤例程（例如顯示或記錄錯誤消息）。

重要的是要知道的是，一些代碼可以觸發客戶端行爲（例如HTTP 401結合某些頭可以觸發瀏覽器中的驗證對話框），你應該知道這些副作用。

在我看來，在響應主體中發送有用的錯誤描述以幫助客戶端修復問題比尋找「完美」的HTTP狀態代碼更重要。我知道REST狂熱分子會不同意，但他們中的任何一個都無法爲每種情況提供正確的HTTP狀態代碼。這就是說，如果你想爲自動化處理髮出細粒度的錯誤代碼/消息，你可以引入自定義的HTTP頭域，例如：http：//www.microsoft.com/downloads/details.aspx?displaylang=zh-cn&hl=zh-CN

X-MyApp-Error-Code: 2.1.6 
X-MyApp-Error-Message: The uploaded file is empty

然後，你將提供一個文檔和/或SDK揭示所有可能的錯誤代碼值X-MyApp-Error-Code到您的API消費者。

來源

2017-01-06 12:31:43 lxg

如果發現上傳的文件爲空，發送ConflictHttpException是否正確 – Tarun

我知道了。感謝您的回答。 – Tarun

不是。 Symfony的ConflictHttpException發出HTTP 409.此代碼表示對資源的訪問衝突，例如，如果上傳會覆蓋（保護）文件。正如我所說的，不要過多地考慮「正確」的代碼...選擇正確的類別（4xx與5xx）並給出一個精確的錯誤信息。 – lxg

適當的Http狀態代碼用於在休息終點上上傳文件

回答

相關問題