Wrong HTTP status 206

[RedGlow]

While I was looking for the /v2/recipes?ids=... endpoint, I noticed that there is a wrong HTTP status management. To sum it up:

• All the ids are known: a 200 status is returned (correct)
• Non of the ids known: a 404 status is returned (and that seems correct to me too)
• Some of the ids are known, and some not: a 206 status is returned. This is not correct.

A 206 status is used for obtaining parts of a content through the use of the range headers: https://tools.ietf.org/html/rfc7233 . In this case, we have a correct answer, so a 200 is in order.

[lye]

I agree that we're breaking the RFC, but we wanted to use a non-200 status code to indicate a partial success.

An RFC-compliant implementation would accept the id list as a Range header (and the server would emit an Accept-Range: ids header in bulk-expanded responses, as per RFC 2616§3.12). Pragmatically, that breaks horribly due to CORS restrictions (the Range header makes the request non-simple, thus requiring a preflight -- and our backend infrastructure doesn't support OPTIONS requests) -- this is the same reasoning behind the ?access_token option (rather than requiring an Authorization header).

I think a good way to think about it is that 206 is the correct status code; it's just that we botched how the requests are sent.

Let me know if you want us to add support for ids sent via a Range header though.

[RedGlow]

I see now the reasoning (and reasons!) behind.

I suppose that a full conformity to the RFC makes sense only when the CORS preflight will be supported on the backend.