Ping Error to https on local net (UNPROCESSABLE_CONTENT 422)

[fernandeusto]

Environment

Docker

Version

0.14.3

Describe the problem

The ping to the apps on the local network using the https protocol returns an error "unexpected response: fetch failed"
The error happens for example with the url of the router or the nas, such as: "https://192.168.x.x" or "https://192.168.x.x:yyyy"
In apps with "https://dominio.com:puerto" the ping works ok
And in apps with "http://19.168..x.x:yyyyy" it also works ok

Logs

Context

No response

Please tick the boxes

• I confirm that I attached the proper logs
• I've read the docs
• I've checked for duplicate issues
• I've tried to debug myself

[SeDemal]

Chances are that local IP's don't use https as this is provided by reverse proxies and under domain names.
That's why it works with domains.
use http instead when using the IP.

[fernandeusto]

Some of my services such as the NAS, the router, or portainer among others, are forced to https even locally and do not open anything with http and returns 400
With the previous version of Homarr, pings to any https on the local IP worked perfectly

[SeDemal]

if they are apps with no integration, set them to http and add 400 in the list of accepted networks.
400 means bad request, so the req is bad but the simple fact that the web page responds means that it can be pinged, thus making 400 an actually valid response in the case of a ping.

I'll look into what changes where done that could make that happen.

[fernandeusto]

If I set them to http and add 400 in the list of accepted networks, the ping is green ok, but then when I click, it does not open the service, it opens the 400 error page. and then homarr does not make sense

[SeDemal]

Sorry I wasn't clear, set the internal to http, external to https.
Internal is the address used by homarr and the external is the link to redirect the user.

[q2doc]

same here... adding 400 does not change status - still fetch failed. Going back to 0.14.2 helps but not my favourite solution 😉

[ajnart]

same here... adding 400 does not change status - still fetch failed. Going back to 0.14.2 helps but not my favourite solution 😉

I don't understand how downgrading could help since we literally didn't touch the ping function for this update 🤔

[fernandeusto]

I also back to 0.14.1
All pings are ok here.

[denis-ali]

Seems that for some requests it's throwing a 422 error:

[duka10]

Version 0.14.2

Version 0.14.3

I just cant figure why it show this fetch failed on some but not on other services.
Cant find difference in my case.

[Cuetojuan]

Some of my services such as the NAS, the router, or portainer among others, are forced to https even locally and do not open anything with http and returns 400
With the previous version of Homarr, pings to any https on the local IP worked perfectly

The same thing happens to me.

[boredgamesdev]

happening for me on HTTPS sites that have invalid certs like NET::ERR_CERT_AUTHORITY_INVALID which worked before the latest update

[manuel-rw]

Are your certificates self signed?
Are you using the correct protocol? (not HTTPS request on HTTP port)
Please post your browser console as well as the server log so we can investigate this issue properly.

[boredgamesdev]

They are self signed and are the correct protocol (HTTPS). I will look in to getting you some logs.

[boredgamesdev]

1704328121620.log
This is the console log, the docker container logs only showed "ERROR Unexpected response: fetch failed"

[c00lkatz]

I also back to 0.14.1 All pings are ok here.

Same here, 0.14.3 has issue with pings on some services, rolled back to 0.14.1 and all good again.

[manuel-rw]

Thanks the log.
I'm almost 100% sure that the headers here are a problem, which have been added in 0.14.3:

homarr/src/server/api/routers/app.ts

Lines 32 to 38 in e208693

	const res = await fetch(app.url, {
	method: 'GET',
	cache: 'force-cache',
	headers: {
	// Cache for 5 minutes
	'Cache-Control': 'max-age=300',
	'Content-Type': 'application/json',

Using git blame, the author is @ajnart :
082077e#diff-bbd263988ae753b34858376351f77c1b563335c3b9d16f765d6bbbc7ca92757cR32

@ajnart can you explain your idea behind the headers? These could definitely interfere with some services and are definitely not needed, since we parse no data nor does the returned data matter in any way.

[ajnart]

You're right this issue is happening since my last commit. I might've put that fetch code there for some unrelated tests and forgot to delete it later. We merged the docker import feature quite late so we didn't detect the changes in the ping system. I will roll back the changes and release them along with the next version

[ajnart]

@manuel-rw The crash might be due to the application/json header crashing if the content of the ping is not json and is for example HTML

[ajnart]

I am having issues replicating the issue, for me pinging anything with HTTPs locally hosted creates an error, Http UNPROCESSABLE_CONTENT 422. Even when using the code from previous version it returns an error for me. Could anyone share their setup / a minimal reproduction of the error ?

[boredgamesdev]

Switching to 0.14.2 returns a 200 for me instead of a 422 on the latest. Both using docker. What else can I do to assist?

0.14.2

[mshorey]

Switching to 0.14.2 returns a 200 for me instead of a 422 on the latest. Both using docker. What else can I do to assist?

0.14.2

Same. I will note the only app links that were showing this error were using self-signed certs. Anything I can contribute to help let me know.

[denis-ali]

I believe I may found the answer of what is happening in this question at Stackoverflow.

It is consistent with the removal of the https from app.ts on line 4, possibly in favor of the fetch method, and the lack of the "rejectUnauthorized", which would circunvent the issue with self signed certificates.

I don't have the means to build a POC to prove it, but it may help @ajnart on getting to a fix.