I've got a symfony2 bundle where I use jquery terminal project. It's a simple javascript console where the user passes some instructions which are executed on server side with AJAX/JSON and returned to the console and displayed. The php server scripts reads the browser-terminal request from $GLOBALS['HTTP_RAW_POST_DATA'].
Currently, when any request throws an error, symfony2 returns a whole HTML response. I don't want the HTML part (I'd like to display the exception message/code only).
The problem is: symfony2 handles exceptions and catches them somewhere, embedding in HTML and returns such response. I want to modify this - the exc. may be caught, but I want no HTML included. There is one distinct bundle, made only for the console stuff.
In fact, the problem was that there was exit statement missing in the controller. The controller response was empty, so an exception was thrown, that a controller has to return a response. After adding exit; after echoing the output, the problem was gone.
Related
I created a standard Blazor Client application, but found when adding any new API controllers they simply do not work.
Even just copying the WeatherForecastController to a WeatherForecast2Controller returns the same error (as an HTML error page is returned instead of any JSON data):
'<' is an invalid start of a value. Path: $ | LineNumber: 0 | BytePositionInLine: 0.
I assume there must be some configuration somewhere to tell it what return type to expect, but no idea where to look. The only controller that returns valid JSON data is the WeatherForecastController you get out of the box.
Works:
group = await Http.GetFromJsonAsync<GenericGroup[]>($"WeatherForecast");
Fails:
group = await Http.GetFromJsonAsync<GenericGroup[]>($"WeatherForecast2");
Controllers are identical aside from name (literally copied the existing controller). I have been through every single file in the solution and don't see anything that would cause WeatherForecast to be a special routing.
Clue 1:
It does not hit a breakpoint in any controller aside from the WeatherForecastController
Clue 2:
The HTML returned (which causes the Json deserialise to fail) is actually the initial Loading... from the Blazor client load, so it looks like the requests are going to the standard routing and not treated as API calls.
Clue 3:
This does not happen unless authentication has been added to the application. I tried it on a vanilla Blazor app (no auth) and it works just fine. The failing app is using Azure B2C for auth.
Turns out you can cause things to blow up if you inject the wrong logger parameter in the generic ILogger<>. It was the one thing I missed changing. Good to know.
I have a webservice method that if I call directly via url GET returns XML without issue.
However, POST to that same url with Content-Type Json, it fails.
I think I can figure out the issue (I'm guessing it's an encoding or bad character somewhere in there) but I don't know how to debug the problem.
If I set a breakpoint in the webservice, it runs to completion. The failure appears to be happening AFTER the method returns, but BEFORE the json is returned to the caller.
How can I get in between to trace the error?
Please let me know if I can provide more context to help, but I really just need to know how to get in there.
EDIT:
The web service is configured to receive POST and return JSON and in fact DOES correctly return JSON in some cases. However, there are certain calls that are failing, so I need a way to trace this or debug it somehow and figure out why some calls are not working.
The web service is likely not configured to receive POST requests, especially if you are receiving a 405 Method Not Allowed response status.
Although I didn't find a way to debug or intercept the request to find the exact answer, it turns out the problem was the size of the content being returned by the webservice. Following this answer: ASP.NET WebMethod with jQuery json, is there a size limit?
and increasing the json limit fixed the issue!
Is there a way I could have trapped this to find the error without just guessing it was a size limit?
As can be seen in AngularJS's source, any $http.post request that returns an HTTP code in the 200-299 range will trigger the success() callback even if the response contains invalid data (like for example invalid JSON).
I'm specifically setting my call's responseType: 'json' and even then the success callback is fired when something else comes back. This is especially annoying in the development server where PHP's display_errors setting is turned on. When something goes wrong server-side and PHP outputs an error message the AngularJS app doesn't detect this and continues happily.
Is there a way to prevent this? I mean, to make the AngularJS app fire the error() callback when the response data is invalid JSON?
Thanks
so your PHP server responds with a 200 error code even on an error? Not knowing PHP, this feels like a server configuration problem to me. I'd expect a 500 error with a payload. That being said, there are two things that I can think of offhand.
$http includes transformResponse handlers you can set up to inspect the response for problems.
$http also includes the concept of "interceptors" which allow you to pick up the response payload and do something with it. You could use an interceptor to "reject" the response.
More information on transformResponse and "interceptors" in the $http documentation:
http://docs.angularjs.org/api/ng.$http
Not a great title but I'm looking more for some guidance, have searched quite a bit. I'm building a web app with an MVC framework (but I think this is a more generic question). I'm trying to make many views that do a lot of AJAX style calls and say I have a site with users and they can add folders and files to their profile page. So the URL maybe like:
/profile/{id}
I have a Profile controller that returns a view with various information. I'd like files and folders listed on the profile to be dynamic so I want to populate it through AJAX calls. I was thinking I would have a URL like
/listFolders/{userId}
and
/listFiles/{folderId}
Is it reasonable to have these URLs return a JSON object for these two URLs and not even provide an HTML view (since, for the browser, the view will just be the whole profile page)? Also, what should I return for errors, say if the user/folder doesn't exist or the current logged in user doesn't have access the data? Is it reasonable to just set 404 or 403 HTTP error codes or do they need to return some kind of HTML? What if there are multiple reasons for it to fail and I'd like to pass that along? Should I arbitrarily choose HTTP error codes or define integer return codes like 0, 1, 2, etc? Also, should the URL specify that they are JSON, like listFoldersJSON instead of listFolders?
I have used JSON in my previous projects. For errors, we return error codes.
We decided to do so because we were dealing with API clients. So we want to deal with error codes (REST is based on HTTP, so it was appropriate to return error codes).
Since you are writing your own application, you can pretty much choose how you want to send your errors to the view. You can create a error json object and in the view you have to check whether this object is not null.
pretty much a if-else in the view. Else you can return error codes and check for the code before rendering the JSON into whatever view you want to.
I would go with error codes, because that complies with the REST philosophy.
Generally speaking, I handle this situation by throwing a 500 internal server error with a status message. Most client libraries such as jQuery provide built in error handling with a failure callback like:
jQuery.ajax({
success:function(response){
//do some success stuff
},
error:function (xhr, ajaxOptions, thrownError){
//handle error
alert(xhr.responseText);
}
});
It's entirely feasible to return JSON objects as opposed to actual views.
As far as the url, you can use listFolders and listFiles without taking on the JSON. However, I recommend you use lower case urls for the sake of how the server is setup. For instance, I know on Apache that sometimes listFiles would be fine, but listfiles would lead to missing page exception.
With regards to errors: You could setup a header of sorts in your JSON response and use whatever system you'd like. For instance, you could do something like
status_code: 0 //where 0 means successful
status_detail:success!
Where, if the status_code is something other than 0, you'd check the status_detail and know to ignore everything else inside the response.
Also, what should I return for errors, say if the user/folder doesn't exist or the current logged in user doesn't have access the data?
These are basic HTTP Error codes:
401 : Unauthorized
404 : Not found
There's a whole slew of error messages in the HTTP spec:
HTTP Status Code Definitions
Also, should the URL specify that they are JSON, like listFoldersJSON instead of listFolders?
Generally, a good way to handle this is for the client to set the 'accepts' header to something like 'text/json' or 'text/xml' and for the server to parse it out and respond with the correct response. This way you can use the same URL but send back different views of the data (if you ever wanted)
I'm trying to standardize the way I handle exceptions in my web application (homemade framework) but I'm not certain of the "correct" way to handle various situations. I'm wondering if there is a best practice from UI/ user-friendly point of view.
User logs into application and opens two tabs showing the same screen. On one tab they issue a delete command on object FOO. Then, in the other tab they then click the edit command on FOO (which no longer exists); e.g. a GET request for editObject.php?object_id=FOO. What should I do when they issue the edit request for this nonexistent object?
-Currently I am redirecting these "missing" objects to the previous page with an error message like "object does not exist".
User issues a GET request to search for Objects with color=Red, e.g. searchObjects.php?color=Red. The query returning these results blew up because somebody dropped the OBJECTS table. This is an unexpected exception and isn't quite the same as 1).
-Currently I am redirecting to errorPage.php with a message "Unexpected error"
In general, what should I do if GET/POST parameters that should be there are instead mysteriously missing. Perhaps somebody is trying to inject something?
-Currently I am treating these the same as 2)
What should I be doing in each of the above 3 cases?
Render a "Object does not exist" view at the url editObject.php?object_id=FOO
Redirect to a controller that displays an error view: header('Location: errorPage.php')
Serve a 404: not sure of the syntax for doing this in PHP/Apache
Other
I'd say render it and serve a 404. That way, the user has the chance to see where they went wrong in the URL, or copy & paste it. If you redirect to a generic error page, they don't have that chance.
The PHP way to serve a 404 is
header("HTTP/1.0 404 not found");