HealthCheckUI (AspNetCore.Diagnostics.HealthChecks) Unexpected Character 'H' error - asp.net-core

I'm having an issue with the AspNetCore HealthCheckUI.
I followed this example:
https://github.com/Xabaril/AspNetCore.Diagnostics.HealthChecks#healthcheckui
My UI is up and running and my services are up and running with a healthcheck that just returns a string "Healthy". And I think that's the root cause of the issue.
It looks like the UI is showing a "false" error because it's expecting JSON and seeing a string. And so it's throwing an "Unexpected character 'H'" error while parsing the response.
Is there a way to stop the healthcheckui from expecting json?
Is there a way have this AspNetCore HealthChecksUI package work with a Healthcheck that doesn't return JSON?

Found the closest thing I could find to an answer, which is basically change all my healthchecks to json :(
https://github.com/Xabaril/AspNetCore.Diagnostics.HealthChecks/issues/440

Related

Splunk REST API error handling with ouput_mode=json OR output_mode=csv

Using the Splunk REST API, i see that XML response will return search syntax errors or warnings.
if you select output_mode="csv" or output_mode="json" and the search had a syntax error, it simply finishes quickly and returns zero results.
Is there a way to change this behavior so that an error in syntax will return an error message instead of just sending back 0 results? I'd like to use JSON and not have to overhaul to support XML.
Searching API documents, I keep coming up empty.

Getting illegal character when sending GET request in JMETER. Working fine in browser

Im getting illegal character in JMETER for GET request -
https://dev1/api/v1/query/job/?filter={%22job_manager_id%22:%22553f2350-12d3-4252-8fe0-39691019c495%22}
tried replacing %22 with "" but still getting illegal character.
Any solutions ?
I think problematic characters are { and }, they need to be percent-encoded
The options are in:
Tick "URL-encode" box next to the filter parameter in the HTTP Request sampler :
Use __urlencode() function in "Path" field like
see Apache JMeter Functions - An Introduction article to learn more about JMeter Functions concept
Or just hard-code the percent-encoded Path part like:
https://dev1/api/v1/query/job/?filter=%7B%22job_manager_id%22%3A%22553f2350-12d3-4252-8fe0-39691019c495%22%7D

Invalid request body error when sending json string as data to an external api using CL_HTTP_CLIENT

We are facing an issue while sending json data to an external api using CL_HTTP_CLIENT.
The JSON data is produced using '/ui2/cl_json=>serialize( data = ls_body compress = abap_true pretty_name = /ui2/cl_json=>pretty_mode-camel_case )' .
when sending this JSON as data the the external api returns status 400 with response as
{ "errorCode": "INVALID_REQUEST_BODY", "message": "The request body is missing or improperly formatted. Unexpected character encountered while parsing value: \u001f. Path '', line 0, position 0." } .
we also stringyfied this JSON Data in backend as it might be due to parsing error but it didnt work.
The same stringyfied data tried to send through browser console using ajax and it did worked without any issue.
could any any one tell us how to handle this json object and send this to external api using CL_HTTP_CLIENT.
Note : JSON STRING is deeply nested .
Thanks in advance..
You can use request catcher service for getting SAP output.
Then check your output has valid json.
Check external api with rest tool like postman or SoapUI. Every developer not track guidliness may be external api has limitations.
The issue was with the unicodes in the string.
these were not accepted by the external api so removed from the string and sent to api and it did worked.
Thanks for You suggestion.

How to properly encode special characters in a REST API url

EDIT: The NHTSA docs, as CBroe points out, say to replace an ampersand with an underscore. However, I'm also getting an error with forward slashes (albeit a different one, page not found, because it's decoding the slash), for example the make 'EXISS/SOONER':
http://www.nhtsa.gov/webapi/api/Recalls/vehicle/modelyear/1997/make/EXISS%2FSOONER?format=json
And replacing the ampersand with an underscore no longer results in an error message, but in zero results returned, which should not be the case.
ORIGINAL POST:
I'm trying to download the content from the following URL:
http://www.nhtsa.gov/webapi/api/Recalls/vehicle/modelyear/1997/make/s&s?format=json
And the site returns the following error message:
Server Error in '/' Application.
A potentially dangerous Request.Path value was detected from the client (&).
The problem is the ampersand; a similar request for a different car make works:
http://www.nhtsa.gov/webapi/api/Recalls/vehicle/modelyear/1997/make/toyota?format=json
I have verified from a different endpoint that S&S is a valid make for the API.
Based on stackoverflow answers, I've tried all the following without success:
http://www.nhtsa.gov/webapi/api/Recalls/vehicle/modelyear/1997/make/s%26s?format=json
http://www.nhtsa.gov/webapi/api/Recalls/vehicle/modelyear/1997/make/s%26amp;s?format=json
http://www.nhtsa.gov/webapi/api/Recalls/vehicle/modelyear/1997/make/s%26amp%3Bs?format=json

Cannot parse feed

I'm trying to parse this feed http://www.bbc.co.uk/sport/football/teams/newcastle-united/rss.xml
I get this message "A feed could not be found at http://. A feed with an invalid mime type may fall victim to this error, or SimplePie was unable to auto-discover it.. Use force_feed() if you are certain this URL is a real feed."
If I use force_feed I get an error "This XML document is invalid, likely due to invalid characters. XML error: Mismatched tag at line 27, column 8" but looking at the xml I can't see any errors. Indeed, checking at http://validator.w3.org/ seems to validate fine.
Any suggestions?
I'm running the latest version of simplepie downloaded a few days ago.
I found the problem when I stripped out the code to create a test case. The url being loaded was http://www.bbc.co.uk//sport/football/teams/newcastle-united/rss.xml (notice the double forward slash). simplepie seems to not be dealing with this gracefully. Removing the double slash fixes the problem