code 400, message Bad request version

[j3mu5]

Hello, the container works fine, the connection via the recipe action works (URL is https://XX.XX.XX.XX:YYYY/ since http does not lead to any results in the log). However, no recipes are being added to Bring, as the log shows:

[2024-07-19 19:52:08,938] [BringHandler] [INFO] [Found the bring list Einkauf (UUID: xxxx)]
[2024-07-19 19:52:08,508] [BringHandler] [INFO] [Login successful]
[2024-07-19 19:54:23,606] [werkzeug] [ERROR] [XX.XX.XX.XX - - [19/Jul/2024 19:54:23] code 400, message Bad request version ('\x02h2\x08http/1.1ÿ\x01\x00\x01\x00\x00#\x00\x00\x00')]
[2024-07-19 19:54:23,600] [werkzeug] [ERROR] [XX.XX.XX.XX - - [19/Jul/2024 19:54:23] code 400, message Bad HTTP/0.9 request type ('\x16\x03\x01\x06À\x01\x00\x06¼\x03\x03\x9eê\x15.\x11rU49¶\x97ðÕ\x02\x90AÄ\x9b')]

Edit: curl -I http://XX.XX.XX.XX:YYYY results in

HTTP/1.1 405 METHOD NOT ALLOWED
Server: Werkzeug/3.0.3 Python/3.10.14
Date: Fri, 19 Jul 2024 20:04:28 GMT
Content-Type: text/html; charset=utf-8
Allow: OPTIONS, POST
Content-Length: 153
Connection: close

[felixschndr]

The problem is that you are doing an HTTPS request (which is encrypted) and the server cannot decrypt it.

Why does HTTP not work?

[j3mu5]

Thanks @felixschndr for the tip! http is the way to go. I have now investigated it further. The command curl -I http://XX.XX.XX.XX:YYYY/status works and returns:

HTTP/1.1 200 OK
Server: Werkzeug/3.0.3 Python/3.10.14
Date: Sat, 20 Jul 2024 07:40:10 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 2
Connection: close

The container also reacts as expected in the logs: [2024-07-20 07:40:10,915] [Main] [DEBUG] [Got a status request]

However, when I add the IP addresses with port (http://XX.XX.XX.XX:YYYY/ including the / ) in Mealie in the recipe actions, I see no reaction to the recipe action your container (and also no recipes in my bring list).

[felixschndr]

Thanks @felixschndr for the tip! http is the way to go.

👍🏻

However, when I add the IP addresses with port (http://XX.XX.XX.XX:YYYY/ including the / ) in Mealie in the recipe actions, I see no reaction to the recipe action your container (and also no recipes in my bring list).

This sounds like that the container can't reach the API to me. When you did curl -I http://XX.XX.XX.XX:YYYY/status I assume you did this anywhere but not in the mealie container, right?

Can you please go into the mealie container and do the curl again and see what happens?

docker exec -it -u root mealie_app /bin/bash # Go into the container
apt update && apt install curl -y # Install curl
curl -I http://XX.XX.XX.XX:YYYY/status

This should also return an OK, but I assume it won't.

[j3mu5]

Strange - the code to execute the curl command in the container works without problems:

docker exec -it -u root mealie_app /bin/bash # Go into the container apt update && apt install curl -y # Install curl curl -I http://XX.XX.XX.XX:YYYY/status

root@fbe3876e44f3:/# curl -I http://XX.XX.XX.XX:YYYY/status
HTTP/1.1 200 OK
Server: Werkzeug/3.0.3 Python/3.10.14
Date: Mon, 22 Jul 2024 12:06:11 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 2
Connection: close

I run my Mealie instance with a self-signed certificate using nginx so that I don't have to deal with ugly IP addresses and ports. In this scenario (when I call the Mealie instance via https://rezepte.mealie - or whatever the URL may be), recipie actions do not add the ingredients to Bring and the log of mealie-bring-api is empty. Is there any way for me to use mealie behind my proxy?

As soon as I open Mealie via an URL with http://IP:Port, the recipe action work; the logs in the container mealie-bring-api show a success and the ingredients end up in Bring.

[felixschndr]

Let me rephrase that to see if I understand you correctly? You are using Nginx as a reverse proxy (so do I) and access Mealie through it. In this case sending the request to the API does not work. When you are using the direct access via IP and port (not over Nginx) the request works.

1. Is this correct?
2. I guess this has something to do with CORS policies. I don't know much about this but I think your browser has some kind of problem sending the request to the API while you are accessing Mealie via HTTPS.
3. Does the browser trust your self signed cert? (I can always recommend to buy a cheap domain and get a LetsEncrpyt cert which the browser will trust, this is what I do)
4. Do you have your Mealie Bring API behind the Nginx as well? As I see it you don't, right? Please try to add the API to a proxy host as well such that it is reachable via HTTPS and see what happens

[j3mu5]

Dear @felixschndr

1. Is this correct? Yes!
2. I guess this has something to do with CORS policies. I don't know much about this but I think your browser has some kind of problem sending the request to the API while you are accessing Mealie via HTTPS. Okay, i dont know much about that.
3. Does the browser trust your self signed cert? (I can always recommend to buy a cheap domain and get a LetsEncrpyt cert which the browser will trust, this is what I do). I created an authority with openssl and imported that in my browser. This works and the certificate ist trusted.
4. Do you have your Mealie Bring API behind the Nginx as well? As I see it you don't, right? Please try to add the API to a proxy host as well such that it is reachable via HTTPS and see what happens Yes, i did not yet use nginx for the mealie bring api.

If the mealie bring api is also behind nginx and I call it via the recipie action (https://rezepte-bring.tld/), I get an error in the bring api:

[2024-07-25 08:21:52,610] [werkzeug] [ERROR] [192.168.0.1 - - [25/Jul/2024 08:21:52] code 400, message Bad HTTP/0.9 request type ('\x16\x03\x01\x00·\x01\x00\x00³\x03\x03')]
[2024-07-25 08:21:18,277] [werkzeug] [ERROR] [192.168.0.1 - - [25/Jul/2024 08:21:18] code 400, message Bad HTTP/0.9 request type ('\x16\x03\x01\x00·\x01\x00\x00³\x03\x03·ï\x9c\x08\x18`')]

Edit: It works now! Problem was me not using http/https correctly in nginx settings. Thanks a lot for pointing me to the solution! 😍

[felixschndr]

Problem was me not using http/https correctly in nginx settings.

Yeah, this ('\x16\x03\x01\x00·\x01\x00\x00³\x03\x03·ï\x9c\x08\x18')]` is casual HTTPS not being decrypted. Glad it works now!