tahoe-lafs/trac-2024-07-25

Upload failures should report useful HTTP status lines #1047

New issue

Open

opened 2010-05-19 00:29:53 +00:00 by kpreid · 0 comments

kpreid commented

2010-05-19 00:29:53 +00:00

Owner

iCal, and perhaps other HTTP-PUT publishing applications, reports only the HTTP status line when the publishing upload fails:

Request for http://dummy@127.0.0.1:9797/uri/URI:DIR2:<redacted>/<redacted>.ics failed.

The server responded with
"HTTP/1.1 500 Internal Server Error"

The actual error was:

allmydata.interfaces.UploadUnhappinessError: shares could be placed on only 5 server(s) such that any 3 of them have enough shares to recover the file, but we were asked to place shares on at least 7 such servers. (placed all 10 shares, want to place shares on at least 7 servers such that any 3 of them have enough shares to recover the file, sent 14 queries to 9 peers, 10 queries placed some shares, 4 placed none (of which 4 placed none due to the server being full and 0 placed none due to an error))

Therefore, the routine which catches and displays this error as the response body should also set the HTTP status code to the most appropriate code for the error (for UploadUnhappinessError, probably 503 Service Unavailable), and set the status text to an abbreviated form of the error message; say "Could not place sufficient shares because servers are full".

iCal, and perhaps other HTTP-PUT publishing applications, reports only the HTTP status line when the publishing upload fails: ``` Request for http://dummy@127.0.0.1:9797/uri/URI:DIR2:<redacted>/<redacted>.ics failed. The server responded with "HTTP/1.1 500 Internal Server Error" ``` The actual error was: allmydata.interfaces.UploadUnhappinessError: shares could be placed on only 5 server(s) such that any 3 of them have enough shares to recover the file, but we were asked to place shares on at least 7 such servers. (placed all 10 shares, want to place shares on at least 7 servers such that any 3 of them have enough shares to recover the file, sent 14 queries to 9 peers, 10 queries placed some shares, 4 placed none (of which 4 placed none due to the server being full and 0 placed none due to an error)) Therefore, the routine which catches and displays this error as the response body should also set the HTTP status code to the most appropriate code for the error (for [UploadUnhappinessError](wiki/UploadUnhappinessError), probably 503 Service Unavailable), and set the status *text* to an abbreviated form of the error message; say "Could not place sufficient shares because servers are full".