8

I'm writing a RESTful API with some endpoints to which clients can PUT or POST chunked files (using flow.js), including a payload digest among the metadata. The server also calculates digest and will throw an error if the digests don't match, in which case the client should attempt to retry the same request with no change (at least until some retry limit is reached).

None of the standard codes seem to fit well by definition. What is the best code to use? Is there any that fits somewhat by convention?

Note: for the purposes of integration with this library, the response must not be 404, 415, 500, or 501 as they will cancel the larger operation rather than retry this portion.

I also cannot use 409 because that is being used to identify attempts to upload multiple copies of the same file, which I believe is a better use of 409 anyway.

HonoredMule
  • 719
  • 11
  • 21
  • If the digests don't match would an unchanged repeat change the outcome? - 400 Bad Request indicates a modified resend is needed. – Alex K. Feb 26 '16 at 16:13
  • 1
    There is no official status code to tell the client to retry (though IIS has a non-standard [449 Retry With](https://msdn.microsoft.com/en-us/library/dd891478.aspx)). I think `400 Bad Request` or `409 Conflict` is probably your best bet. Or, just make up your own custom code. – Remy Lebeau Feb 26 '16 at 16:15
  • @RemyLebeau While those work they specify an issue on the client side. Normally a 500 would be the correct response here as there is an error server side with no specific message suitable but that is restricted. So, as explained in my answer, I would go with a 501 – Matthew Verstraete Feb 26 '16 at 16:32
  • 1
    @MatthewVerstraete IMO this is a validation-check issue (client sent something and claimed it has a certain hash while the server calculated something different). Therefore it is probably not the server's fault (unless it uses a wrong hash function) but a sender's fault and should therefore be in the 400-ish range – Roman Vottner Feb 26 '16 at 16:58
  • I believe it would be fair to say the problem is not server-side, and that it may not be client side either. After some retries, a 400 response is probably most appropriate, but it really seems there ought to be something else for the server to send when it wants to suggest an unmodified retry. I guess what it comes down to is there is no response range for transport errors so it has to get wedged into the client errors. – HonoredMule Feb 27 '16 at 04:19

3 Answers3

6

I think more appropriate status code when same data from user going wrong, like corrupted data is:

400 Bad Request

For me corrupted data, means like syntax error caused by the transmission of data, semantically correct but syntactically erroneous.

422 Unprocessable Entity maybe apply too. https://www.rfc-editor.org/rfc/rfc4918#section-11.2

Community
  • 1
  • 1
Steven Koch
  • 629
  • 7
  • 9
2

I cannot accept Matthew's answer because it's still suggesting one of the values I'm excluded from using - and I also believe 5xx errors aren't very appropriate where the error is in the client or the transport layer.

While still looking for better options, I'll for now propose (and use) a non-standard 4xx error, especifically

419 Checksum failed

That particular value is being chosen for its proximity to codes handling errors of a similar nature and similarity to 409 which is perhaps the closest relation.

An anser will be chosen after a couple days, to provide opportunity for community concensus on a best practice approach.

HonoredMule
  • 719
  • 11
  • 21
0

I am not aware of a standard or specific error number for a case like this but normally I would use 415 or 500. Since you are restricted from using those options I would go with a 501. Technically a 501 is a "not implemented" but it is used in cases where there server does not recognize the request OR the server lacks the ability to fulfill the request. You could argue that a checksum error makes it impossible for the server to fulfill the request.

If you want to see a list of all the options check out this wiki page and you might find something you like better

Matthew Verstraete
  • 6,335
  • 22
  • 67
  • 123