Should I pass the 403 on to the client so they know to work on their account permissions? Should I return a 424 since there was a problem with a dependent service, or should my response be a 5xx status code?
I've scoured the internet and have been unable to find anything useful, although I imagine this is a fairly common situation. Thanks in advance.
Right now, a request sent to a valid DataPower port with an invalid URI is answered with http 500.
This has been deemed to be a security risk, and I am looking for a way to reconfigure it so that it instead causes a connection termination, or anything that wouldn't inform a possible attacker that they have found an active port.
For example: if a valid WSP URL is http://datapower:80/abc, I would like someone who tries http://datapower:80**/a** to get the same result as someone who tries http://datapower**:90/**abc.
The only way I know of to return a custom error code is through a gateway script in a Policy object, which is obviously irrelevant to wrong URI calls that don't activate a WSP/MPGW.
Is there any way to arrange this in DataPower?
So I made a copy of my jmx file and obfuscated the domain to include here. Be kind. I am a load testing noob. :)
I have a load testing target. I must be on the VPN to access the target's website. When connected to the VPN, my load test numbers make no sense. This is cool. I am not convinced I have the test created correctly. But what is weirder still is that when I am NOT connected to the VPN the requests receive a response. The results tree has pretty little green checkmarks (well really shield icons). But there is no way it should have been able to communicate with the server. But when I look at response body, it is a very reasonably approriate response body.
My jmx file is too big. I will try to attach it. But does anyone have an explanation for what might be going on? Or what I might have done wrong?
These "pretty little green checkmarks" doesn't mean that you're hitting the correct server, JMeter automatically treats HTTP Status Codes below 400 as successful so my expectation is that you're basically hitting some form of VPN web gateway login page or something like this and JMeter considers these redirects as successful responses.
You can inspect request and response details using View Results Tree listener and see what exact host you're hitting and what does the response say.
Going forward in order to protect yourself from these "false positive" results you can consider adding Response Assertions to your requests to ensure that response contains what it is supposed to be containing or alternatively doesn't contain errors
I'm developing an application which acts as an Http-Proxy for serving files from an external resource. It actually downloads the file from the external resource, checks for viruses and if the file is not infected, returns the file to the client.
My problem is, in case of the file is infected, what HTTP Status code my service should return? I suppose that any type of 4xx error codes is not appropriate for that situation because this class of code is intended for Client errors.
Is a 502 (Bad Gateway) error more appropriate?
Is there any kind of Standard that covers this situation?
I think you are right maestromarko : 502 Bad Gateway. Read the specifications here:
The 502 (Bad Gateway) status code indicates that the server, while
acting as a gateway or proxy, received an invalid response from an
inbound server it accessed while attempting to fulfill the request.
Your proxy is acting as a Gateway and he received what it conciders is invalid as there are virus in it.
It is not a 4xx class error, because whatever the client changes in the request, the result will still be an error.
See also this decision diagram
Http response codes are only meant to handle http specific conditions so I don't think there is a correct answer as such. But some possibilities...
204 - "The server successfully processed the request and is not returning any content"
403 - "The request was valid, but the server is refusing action"
https://en.m.wikipedia.org/wiki/List_of_HTTP_status_codes
What is optimal HTTP response Code when not reporting 200 (everything OK) but error in input?
Like, you submit some data to server, and it will response that your data is wrong
using 500 looks more like Server Issue
using 200 with warning/error response text is bad (allowing caching and everything is not OK)
using 204 and returning nothing, is maybe good (but well supported?)
using 404 is wrong if requested path (script) is available and in proper place
We had the same problem when making our API as well. We were looking for an HTTP status code equivalent to an InvalidArgumentException. After reading the source article below, we ended up using 422 Unprocessable Entity which states:
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.
source: https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm
Codes starting with 4 (4xx) are meant for client errors. Maybe 400 (Bad Request) could be suitable to this case? Definition in http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html says:
"The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. "
409 Conflict could be an acceptable solution.
According to: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.
The doc continues with an example:
Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.
In my case, I would like to PUT a string, that must be unique, to a database via an API. Before adding it to the database, I am checking that it is not already in the database.
If it is, I will return "Error: The string is already in the database", 409.
I believe this is what the OP wanted: an error code suitable for when the data does not pass the server's criteria.
I recommend using 418 when client request something absurd that the server can't process. Like the server is a teapot but client is requesting coffee kind of stuff. Here is all the (400–499) client side error messages: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#client_error_responses
404 - Not Found - can be used for The URI requested is invalid or the resource requested such as a user, does not exists.