my head is spinning cause of the following issue. I'm accessing my webservice (running on my localhost:4434) with AngularJS and if something goes wrong, the webservice sends a response 400 containing a json body which contains a message that tells you what exactly went wrong.
Problem is I cannot access the message on the client? It is almost as if it never reaches the client?? (This isn't the case, I've confirmed that it reaches the client already) This is the angular code that I use on the client site.
$scope.create = function() {
$http.post('http://localhost:4434/scrapetastic/foo', $scope.bar).
success(function(data, status, headers, config) {
console.log("Call to log: "+status);
console.log("Call to log: "+data);
}).
error(function(data, status) {
console.log("Error|Data:"+data);
console.log(status);
});
}
If I submit malformed data a corresponding error response is generated but as I said ... somehow I cannot access the message that is contained in the response body. This is what I get:
I've tried all sorts of things but am seriously stuck now...perhaps someone has an idea on how to access the payload of the response or at least what to do next? I'm also dealing with CORS perhaps it has something to do with that.
Thanks!
I'm going to take a wild guess here and say that your problem is an XSS issue.
Not only do you not have the data variable, but as far as I can tell from your screenshot, status == 0.
Your screenshot also says Origin: http://localhost, which makes this request considered XSS (since the port is different). That would explain why status is 0.
Edit: You can use jsonp to get around the issue.
Related
I have seen a lot applications using REST API returning a status code inside theirs response bodies, although the HTTP response returns the status code just fine. Is there any reason to put the status code also in the body of the response?
Some APIs return a 200 for all requests, even erroneous ones, and put a status code in the response body. This status code might mimic HTTP status codes, but doesn't have to. One could start numbering your response statuses from 1 for all anyone cares.
Other APIs return appropriate HTTP status codes, and indeed, put the same status code in the response. That's just a waste of bandwidth and brain cells, and a cause for lots of head scratching. It's unnecessary. Except...
It might be useful for some kinds of client libraries. When a client application uses a library that abstracts away all the HTTP stuff, it can just return an object to the programmer that contains all information about the response.
Something like:
{
"status": 200,
"data": {
"foo" : "bar"
}
}
And:
{
"status": 401,
"data": null,
"message": "You are not authorized."
}
This way the library author can chuck the HTTP status code into the object's status property, and the caller doesn't have to deal with exception handling.
But then still there's no reason for the API to respond with it both in HTTP status code and response.
Is there any reason to put the status code also in the body of the response?
Yes, in the sense that the status-line is HTTP metadata, describing the semantics of the response message. Like other HTTP metadata, it's not really designed for use by the end client.
Consider the web experience - the browser gets to see the HTTP response message, and can act on it. But what information do you want to share with the user? In cases where you wanted the user to be aware of the HTTP status code, you would include it in the HTML representation also.
Problem Details for HTTP APIs includes an optional status field in its schema to surface that information for the client.
Does anyone know what could cause ERROR 415 (Unsupported Media Type)? Thank you
createArticleOld : async ({ commit, dispatch }, data) => {
let added = await dispatch('authorizedPostOld',
{ action: 'article',
data,
headers: {
'Content-Type': 'application/json-patch+json',
'Accept': 'application/json-patch+json',
},
}
)
console.log(added)
commit('ADD_ARTICLE', added)
},
Typically, an HTTP response status of 415 is telling you that the format of the data you're sending isn't accepted by the server, as described briefly here:
The origin server is refusing to service the request because the payload is in a format not supported by this method on the target resource.
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.
So, to solve the problem, you need to find out the format that the server expects to receive data in, and send that. The easiest way will be to check the documentation for (or ask the developer of) the server.
If you check the raw response returned to your browser (or perform the same request via something like cURL or Postman), you might find some clues in there as to the formats that the endpoint accepts, or the specific problem causing the error response.
Of course, this relies on the developer of the server implementing the HTTP statuses correctly, and it's quite possible that they've made an error. As a complete guess, given that you're setting the Accept header, it could be that the server is trying to tell you that it can't give you a response in the format "application/json-patch+json", although that should give you a 406.
I'm developing some APIs with Laravel 5.5
The methods I am using are only 'GET'/'POST'/'PUT'/'PATCH'/'DELETE'.
All works fine except if the request is HEAD or LOCK (for example) ....
In this case, the backend returns a 405 error with an html response. And in this html response there are a lot confidential data.
Is it possible , only for some methods, that the back returns a single text "Method not allowed" and not an html file ? Is it a good practice to do that or not necessary?
I imagine a middleware, but which one?
The reason you're getting debug information with confidential data is likely due to debug being set to true in your config. If you turn this to false, the error message will remove the confidential data.
I found a solution.
File Exceptions/handler.php, method render, I had this:
if ($request->is('api/*') and ! in_array($request->method(), ['get', 'post', 'put', 'delete']) ){
return response()->json("request not allowed", 405);
}
It works fine. Now I receive a JSON response instead of an HTML response for all my API routes, depending on 'get/put/post/delete'.
I'm writing a microservice in Play. I'd like my controller to be able to generate client errors (4xx) with a particular JSON response body. However, Play's default HttpErrorHandler kicks in, and replaces my response body with an HTML document.
How can I have my response returned to the client untouched?
I have looked into providing a custom HttpErrorHandler, but this doesn't give access to the response that my controller had generated; the signature is:
def onClientError(request: RequestHeader, statusCode: Int, message: String): Future[Result]
Edit: I can no longer reproduce this problem. Now, the error handler doesn't kick in -- which is the behaviour I'd expect. Most likely some form of user confusion / error.
A client error is a condition which is caused by the client, and Play doesn't know how to handle. That includes malformed headers, non-existing resources (read : No route available for that path).
In all cases, this won't hit a controller : It's handled before it's routed. That also means there is no body that can be passed along.
If it does hit a controller, you're free to return a Result with the proper response code and body. If it doesn't hit a controller, and the error handler is invoked, you need to return a response based on the request itself.
An example of what you're trying to achieve would be handy, since it's a bi t unclear to me.
I just graduated from a front-end development bootcamp and am experiencing my very first technical test. It all seems very straightforward with the exception of one aspect that I'm hoping to get some opinions on. I'm not quite sure what the company is asking here and was wondering if anyone might be able to interpret it better?
I am to recreate the profile section (name, email, etc.) of a webpage with HTML and CSS, which I understand how to do. There's a JavaScript component involving an HTTP POST request that I'm confused about. There are backend APIs that perform the changing of the profile section.
I was not given the URL for the AJAX call, and was instead provided with the following instructions: "can comment out the actual line that makes AJAX call. Simply assume that you’ll get 200 response with empty string as body. Assume csrf_token to be #####". I've been provided the numbers but have omitted them. Additionally, there was also this line: "the backend API accepts POST request with application/x-www-form-urlencoded body".
In my bootcamp I had not done any POST requests, only GET. Is anyone able to provide some guidance on what exactly this question is asking for? My first step would be to use POSTMAN but without a URL, not sure how to go about this.
EDIT:
From various Googling on how these requests are made, I've so far come up with the below code but still missing a lot (probably). The idea is that if a user were to enter in a new email (or new name, password, etc.), a POST request will be made to make this update.
I've been informed that I'm not allowed to use any jQuery for this test, so I've been trying to learn how to do this in JavaScript alone. Additionally, I'm also not sure where the csrf_token comes in.
var xhr = new XMLHttpRequest();
var url = /* URL */;
var params = ;
xhr.open('POST', url, true);
xhr.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');
xhr.setRequestHeader('Content-length', params.length);
xhr.setRequestHeader('Connection', 'close');
xhr.onreadystatechange = function () {
if (xhr.readyState == 4 && xhr.status == 200) {
alert(xhr.responseText);
}
};
xhr.send(params);
My understanding is that you don't actually have to make the request, only have its place ready in code, maybe commented out. Your code should have a hard-coded 200 OK "response" from the API with an empty body, indicating that changing the profile worked. So that one line that actually makes the request could be replaced with something like a mock object for the request result and you could use that (but the text says the response is empty anyway, so you don't need to mock a lot).
I think your code should still show (in a comment, or in preceding request setup lines before the actual commented out request) how you would make the request, how you would pass the csrf token, how you would set the content-type of the request to application/x-www-form-urlencoded if anything needs to be done (probably not), and how you would pass parameters in that format.