Bad encoding for healthchecks payload results in HTTP 500 Server Error #260

New Issue

Closed

opened 2019-11-28 14:10:28 +00:00 by mwalbeck · 5 comments

mwalbeck commented 2019-11-28 14:10:28 +00:00

Copy Link

Thanks a lot for this project, it's fantastic.

What I'm trying to do and why

I've noticed that my backup where sometimes failing according to healthchecks, but the logs showed everything working. The logs also showed both the start and end ping being sent but only the start ping was registered by healthchecks.

I then realized that whenever there were files with non-standard characters in the filename, the end healthcheck with the payload, wouldn't arrive.

I frequently have files with æ, å or ø in the filenames.

Steps to reproduce (if a bug)

Send a POST request to healthchecks with requests library, where the data is a non standard character.

requests.post("HEALTHCHECKS_URL", data="å")

Actual behavior (if a bug)

Results in a HTTP 500 Server error from healthchecks, which results in the ping not going through and the check failing after the grace period.

Expected behavior (if a bug)

Healthchecks should be pinged, and the status code of the response should be HTTP 200.

Other notes / implementation ideas

All backups are run as normal, only the healthcheck fails.

This can be fixed by encoding the data payload as UTF-8 before sending it. If we make the following post request it goes through.

requests.post("HEALTHCHECKS_URL", data="å".encode("utf-8"))

Environment

borgmatic version: 1.4.15

borgmatic installation method: pip

Borg version: 1.1.9

Python version: 3.7.3

operating system and version: Debian 10

Thanks a lot for this project, it's fantastic. #### What I'm trying to do and why I've noticed that my backup where sometimes failing according to healthchecks, but the logs showed everything working. The logs also showed both the start and end ping being sent but only the start ping was registered by healthchecks. I then realized that whenever there were files with non-standard characters in the filename, the end healthcheck with the payload, wouldn't arrive. I frequently have files with æ, å or ø in the filenames. #### Steps to reproduce (if a bug) Send a POST request to healthchecks with requests library, where the data is a non standard character. requests.post("HEALTHCHECKS_URL", data="å") #### Actual behavior (if a bug) Results in a HTTP 500 Server error from healthchecks, which results in the ping not going through and the check failing after the grace period. #### Expected behavior (if a bug) Healthchecks should be pinged, and the status code of the response should be HTTP 200. #### Other notes / implementation ideas All backups are run as normal, only the healthcheck fails. This can be fixed by encoding the data payload as UTF-8 before sending it. If we make the following post request it goes through. requests.post("HEALTHCHECKS_URL", data="å".encode("utf-8")) #### Environment **borgmatic version:** 1.4.15 **borgmatic installation method:** pip **Borg version:** 1.1.9 **Python version:** 3.7.3 **operating system and version:** Debian 10

witten commented 2019-11-28 18:08:40 +00:00

Owner

Copy Link

Thank you so much for reporting this! What an embarrassing bug. 😄 I'll have to audit the other monitoring integrations for similar unicode issues.

Thank you so much for reporting this! What an embarrassing bug. :smile: I'll have to audit the other monitoring integrations for similar unicode issues.

witten added the

bug

label 2019-11-28 18:08:47 +00:00

mwalbeck commented 2019-11-30 10:38:40 +00:00

Author

Copy Link

Character encoding just quickly becomes confusing when we don't all use unicode. From what I can see it's caused by the requests library, which is using latin1 encoding by default, when you pass it a string. There is an issue relating to this on github. Technically passing a string directly isn't supported, but one should encode the string before sending. The main problem is that it isn't properly documented and even though it's not intended, it's still allowed, and it works most of the time.

Here is the issue if you are curious, https://github.com/psf/requests/issues/4503

Character encoding just quickly becomes confusing when we don't all use unicode. From what I can see it's caused by the requests library, which is using latin1 encoding by default, when you pass it a string. There is an issue relating to this on github. Technically passing a string directly isn't supported, but one should encode the string before sending. The main problem is that it isn't properly documented and even though it's not intended, it's still allowed, and it works most of the time. Here is the issue if you are curious, https://github.com/psf/requests/issues/4503

witten commented 2019-11-30 22:44:15 +00:00

Owner

Copy Link

I appreciate the background. Looks like Healthchecks has "fixed" their 500 for the reproduction steps since you first posted it. But non-UTF-8-encoded text just shows up now as "[binary data]" in the UI instead of causing a 500 or appearing correctly as the original payload text. So I'll still be making the encoding fix as you suggested.

I appreciate the background. Looks like Healthchecks has "fixed" their 500 for the reproduction steps since you first posted it. But non-UTF-8-encoded text just shows up now as "[binary data]" in the UI instead of causing a 500 or appearing correctly as the original payload text. So I'll still be making the encoding fix as you suggested.

witten referenced this issue from a commit 2019-11-30 22:53:28 +00:00

Fix for missing Healthchecks monitoring payload or HTTP 500 due to incorrect unicode encoding (#260).

witten commented 2019-12-01 00:59:57 +00:00

Owner

Copy Link

Fixed in borgmatic 1.4.16, just released. Thanks again for reporting this!

Fixed in borgmatic 1.4.16, just released. Thanks again for reporting this!

witten closed this issue 2019-12-01 00:59:57 +00:00

mwalbeck commented 2019-12-01 10:53:46 +00:00

Author

Copy Link

I just updated, It works perfectly. Thank you, your work is greatly appreciated.

I just updated, It works perfectly. Thank you, your work is greatly appreciated.

🎉 1

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

spot-check

1.8.10

1.8.9

1.8.8

1.8.7

1.8.6

1.8.5

1.8.4

1.8.3

1.8.2

1.8.1

1.8.0

1.7.15

1.7.14

1.7.13

1.7.12

1.7.11

1.7.10

1.7.9

1.7.8

1.7.7

1.7.6

1.7.5

1.7.4

1.7.3

1.7.2

1.7.1

1.7.0

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.24

1.5.23

1.5.22

1.5.21

1.5.20

1.5.19

1.5.18

1.5.17

1.5.16

1.5.15

1.5.14

1.5.13

1.5.12

1.5.11

1.5.10

1.5.9

1.5.8

1.5.7

1.5.7.dev0

1.5.6

1.5.5

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.22

1.4.21

1.4.20

1.4.19

1.4.18

1.4.17

1.4.16

1.4.15

1.4.14

1.4.13

1.4.12

1.4.11

1.4.10

1.4.9

1.4.8

1.4.7

1.4.6

1.4.5

1.4.4

1.4.3

1.4.2

1.4.1

1.4.0

1.3.26

1.3.25

1.3.24

1.3.23

1.3.22

1.3.21

1.3.20

1.3.19

1.3.18

1.3.17

1.3.16

1.3.15

1.3.14

1.3.13

1.3.12

1.3.11

1.3.10

1.3.9

1.3.8

1.3.7

1.3.6

1.3.5

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.18

1.2.17

1.2.16

1.2.15

1.2.14

1.2.13

1.2.12

1.2.11

1.2.10

1.2.9

1.2.8

1.2.7

1.2.6

1.2.5

1.2.4

1.2.3

1.2.2

1.2.1

1.2.0

1.1.15

1.1.14

1.1.13

1.1.12

1.1.11

1.1.10

1.1.9

1.1.7

1.1.6

1.1.5

1.1.4

1.1.3

1.1.2

1.1.1

1.1.0

1.0.3

1.0.2

1.0.1

1.0.0

0.1.8

0.1.7

0.1.6

0.1.5

0.1.4

0.1.3

0.1.2

0.1.1

0.1.0

0.0.7

0.0.6

0.0.5

0.0.4

0.0.3

0.0.2

Labels

Clear labels   

bug

  

data loss

  

design finalized

  

good first issue

  

new feature area

  

question / support

  

security

  

waiting for response

No Label

bug

data loss

design finalized

good first issue

new feature area

question / support

security

waiting for response

Milestone

Clear milestone

No items

No Milestone

Assignees

Clear assignees

No Assignees

2 Participants

Notifications

Subscribe

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: borgmatic-collective/borgmatic#260

No description provided.