My application allows file upload. As a restriction I want to restrict files with only certain extension (say pdf for example)
So in case a file with pdf extension is uploaded, I return 200/201 ok status code to indicate the successful upload.
I am confused, what should I return for non-pdf files after reading multiple answers-
400 - argument to return 400 bad request is that request failed due to validation. Argument to not to use is sometime it also indicates syntactical error while making the request.
415 - argument to return 415 Unsupported Media is that file extension is not same. (Considering Media as file), but content type (multipart/form-data) matches and is supported.
422 - Argument to use 422 unprocessable entity is that server understands the content-type (multipart/form-data) but still can't process the request. But other though is, it can still process if the use case is only to upload the file.
From MDN:
415 Unsupported Media Type
The HTTP 415 Unsupported Media Type client error response code indicates that the server refuses to accept the request because the payload format is in an unsupported format.
The format problem might be due to the request's indicated Content-Type or Content-Encoding, or as a result of inspecting the data directly.
I think the last sentence specifically suggests that 415 is not strictly for unsupported Content-Type headers.
Related
The data could not have been inputted by a typical user due to client-side validation. Is "400 Bad Request" the appropriate status code?
If you are certain the form is invalid 400 Bad Request is acceptable. However depending on why you believe a form is invalid you may also choose to use
status code 422 Unprocessable Entity.
This status code is designed to handle the use case where an submitted request is understood by the server and the request is syntactically correct, but the server was unable to process the instructions contained within the request.
Another possibly appropriate error code would be 415 Unsupported Media Type. This error code should be used when the server fails to understand the request due to an invalid type of form. For example, if a server expected a JSON value but was given XML it should in theory return a 415 Unsupported Media Type code.
We have a REST API to fetch binary files from the server.
The requests look like
GET /documents/e62dd3f6-18b0-4661-92c6-51c7258f9550 HTTP/1.1
Accept: application/octet-stream
For every response indicating an error, we'd like to give a reason in JSON.
The problem is now, that as the response is not of the same content type as the client requested.
But what kind of response should the server produce?
Currently, it responds with a
HTTP / 1.1 406 Not Acceptable
Content-Type: application/json
{
reason: "blabla"
...
}
Which seems wrong to me, as the underlying issue is, that the resource is not existing and not the client requesting the wrong content type.
But the question is, what would be the right way to deal with such situations?
Is it ok, to respond with 404 + application/json although application/octet-stream was requested
Is it ok, to respond with 406 + application/json, as the client did not specify an application/json as an acceptable type
Should spec been extended so that the client should use the q-param - for example, application/octet-stream, application/json;q=0.1
Other options?
If no representation can be found for the requested resource (because it doesn't exist or because the server wishes to "hide" its existence), the server should return 404.
If the client requests a particular representation in the Accept header and the server is not available to provide such representation, the server could either:
Return 406 along with a list of the available representations. (see note** below)
Simply ignore the Accept header and return a default representation of the resource.
See the following quote from the RFC 7231, the document the defines the content and semantics of the HTTP/1.1 protocol:
A request without any Accept header field implies that the user agent will accept any media type in response. If the header field is present in a request and none of the available representations for the response have a media type that is listed as acceptable, the origin server can either honor the header field by sending a 406 (Not Acceptable) response or disregard the header field by treating the response as if it is not subject to content negotiation.
Mozilla also recommends the following regarding 406:
In practice, this error is very rarely used. Instead of responding using this error code, which would be cryptic for the end user and difficult to fix, servers ignore the relevant header and serve an actual page to the user. It is assumed that even if the user won't be completely happy, they will prefer this to an error code.
** Regarding the list of available representations, see this answer.
Using a following API:
feed?url=XXX
Validations performed on the parameter url:
If missing: 400 Bad Request
If empty/invalid URL: 422 Unprocessable Entity
If URL don't point to a valid RSS/Atom feed: 422??
What status error should be returned for the 3.?
Unlike validation 2., it is not possible to check the 3. without fetching data and trying to parse it, so raw user data can't be directly validated.
I was thinking about 422 Unprocessable Entity because it is related to validation even if is not directly the data (url) but the reference of this data (content of the url).
What is your opinion?
422 is inappropriate for #2 and #3. It relates to the server understanding the Content-Type header, but the actual content in the HTTP request body could not be interpreted.
I think you could make the argument that 502 Bad Gateway is appropriate here. It's a bit weird because the problem is both user error (incoming url parameter, so a 4xx code), but also it's kind of happening on the server, and in particular an origin server (which makes sense as a 5xx and specifically 502).
But if in this context you strictly consider this an issue that the client caused (bad input in the url) and not server-side, then I would say that there's not a specific enough error code for this, and you should probably just stick to 400 for all of them.
And maybe.. perhaps you can make the argument that 409 might work here. A 409 can used in a case where:
There is nothing in particular wrong with the HTTP request perse.
But the state of another resource is causing the request to fail.
Typically that 'other resource' lives in the same system, but I don't see why the external Atom feed could also not be considered as conflicting.
Because if the Atom feed on the external server is 'fixed', then the original HTTP request that the user made will now work. So a 409 kind of is appropriate here.
I have added versioning for the media types (xml/json) supported in my ReST services. The Accept header of the incoming request should have a media type with valid version to get a proper response in the specified format. The problem is that if the request contains a valid data format in the accept header but an invalid version (or no version specified) I have to give error response in that particular data format.
For example, let the valid media types be application/xml+v2 and application/json+v2. If the request header contains only application/xml or application/xml+v1 I have to give error response in xml and if the header contains application/json+v1 I have to give error response in json.
Do you have to provide custom error message in case of wrong (unsupported) media type? Isn't it enough to use proper HTTP error code: 415 Unsupported Media Type and leave body of response empty?
In case if media type doesn't contain version I will assume that client request the newest available version.
What is the most appropriate response code to return when using the PUT method to update a resource, and the request contains some data that would invalidate the domain rules?
For example, a customer resource must have a name specified. If an agent tries to issue a PUT without supplying a name I don't want to update the resource, and I want to tell the caller that they need to supply a name.
What HTTP response code?
How about 422?
"The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions."
RFC 4918, Section 11.2
The response code is not related to the http method in this case. You should return the same status code as if it had been a POST request. I'd say you should use 400 or 409 (Note: See further discussion of the difference between the two in the comments).
I would return a 400. Strictly, this is for "malformed syntax" (not invalid data), but in practice the YouTube, Twitter, etc. use it for more generally "bad" requests.