starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Parse Error: Invalid header value char #23

New issue

Closed

opened 2026-02-28 01:32:08 -05:00 by deekerman · 15 comments

deekerman commented

2026-02-28 01:32:08 -05:00

Owner

Originally created by @cirrusflyer on GitHub (Jul 12, 2021).

Removed old Docker image and setup latest 1.0.1. Added a check to a website that was successfully being checked prior. Getting this error:

Parse Error: Invalid header value char

Have another site that's still working fine. So this error is new with this new version.

Originally created by @cirrusflyer on GitHub (Jul 12, 2021). Removed old Docker image and setup latest 1.0.1. Added a check to a website that was successfully being checked prior. Getting this error: Parse Error: Invalid header value char Have another site that's still working fine. So this error is new with this new version.

deekerman closed this issue

2026-02-28 01:32:10 -05:00

deekerman commented

2026-02-28 01:32:13 -05:00

Author

Owner

@louislam commented on GitHub (Jul 12, 2021):

I think it caused by invalid http response header rather than 1.0.1 itself, because 1.0.1 just added User-Agent and nothing else in this part.

@louislam commented on GitHub (Jul 12, 2021): I think it caused by invalid http response header rather than 1.0.1 itself, because 1.0.1 just added User-Agent and nothing else in this part. Related issue: https://github.com/nodejs/node/issues/27711

deekerman commented

2026-02-28 01:32:14 -05:00

Author

Owner

@cirrusflyer commented on GitHub (Jul 12, 2021):

Thanks. I wonder why it was working fine in earlier version.

@cirrusflyer commented on GitHub (Jul 12, 2021): Thanks. I wonder why it was working fine in earlier version.

deekerman commented

2026-02-28 01:32:14 -05:00

Author

Owner

@cirrusflyer commented on GitHub (Jul 15, 2021):

I see the Incapsula WAF reference here as well, which is what we use. Any way to make the changes others are suggesting to resolve this issue?

@cirrusflyer commented on GitHub (Jul 15, 2021): I see the Incapsula WAF reference here as well, which is what we use. Any way to make the changes others are suggesting to resolve this issue?

deekerman commented

2026-02-28 01:32:14 -05:00

Author

Owner

@gufastian commented on GitHub (Aug 26, 2021):

Getting the same issue on apparently well configured websites.

@gufastian commented on GitHub (Aug 26, 2021): Getting the same issue on apparently well configured websites.

deekerman commented

2026-02-28 01:32:14 -05:00

Author

Owner

@adumont commented on GitHub (Oct 4, 2021):

Same issue here for some webs (also a web protected by Incapsula ... btw)

@adumont commented on GitHub (Oct 4, 2021): Same issue here for some webs (also a web protected by Incapsula ... btw)

deekerman commented

2026-02-28 01:32:14 -05:00

Author

Owner

@louislam commented on GitHub (Oct 4, 2021):

You should report to Incapsula, because they are corrupted your http header.
Uptime Kuma here to tell your that.

@louislam commented on GitHub (Oct 4, 2021): You should report to Incapsula, because they are corrupted your http header. Uptime Kuma here to tell your that.

deekerman commented

2026-02-28 01:32:14 -05:00

Author

Owner

@cirrusflyer commented on GitHub (Feb 3, 2022):

Just an update. I spoke with Incapsula (Imperva) and they stated this:

"I suspect that this is being caused by our client classification cookie, which is a malformed cookie by design...The client classification cookie is just one of many different client classification methods that we use, so disabling it will not increase the security risk towards the site."

I also know that Uptime Robot, OhDear!, and others don't have this issue. What's unique about Kuma?

@cirrusflyer commented on GitHub (Feb 3, 2022): Just an update. I spoke with Incapsula (Imperva) and they stated this: "I suspect that this is being caused by our client classification cookie, which is a malformed cookie by design...The client classification cookie is just one of many different client classification methods that we use, so disabling it will not increase the security risk towards the site." I also know that Uptime Robot, OhDear!, and others don't have this issue. What's unique about Kuma?

deekerman commented

2026-02-28 01:32:14 -05:00

Author

Owner

@simmessa commented on GitHub (Mar 18, 2022):

Hi there,

for the people coming here for a fix I just wanted to add that if you're running uptime-kuma in docker container and you see this issue (maybe you're unlucky enough to be forced to monitor resources behing incapsula malformed cookies) you can quickly fix by launching the docker container with --insecure-http-parser like this:

docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1 node --insecure-http-parser server/server.js

Please make sure the --insecure-http-parser goes before the js file for this to work.

Hope it's useful to you all.

p.s.:
Please do some research on the security implications of using that --insecure-http-parser switch, there's more here: https://nodejs.org/docs/latest-v12.x/api/cli.html#cli_insecure_http_parser

@simmessa commented on GitHub (Mar 18, 2022): Hi there, for the people coming here for a fix I just wanted to add that if you're running uptime-kuma in docker container and you see this issue (maybe you're unlucky enough to be forced to monitor resources behing incapsula malformed cookies) you can quickly fix by launching the docker container with --insecure-http-parser like this: ``` docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1 node --insecure-http-parser server/server.js ``` Please make sure the --insecure-http-parser goes before the js file for this to work. Hope it's useful to you all. p.s.: Please do some research on the security implications of using that --insecure-http-parser switch, there's more here: https://nodejs.org/docs/latest-v12.x/api/cli.html#cli_insecure_http_parser

deekerman commented

2026-02-28 01:32:14 -05:00

Author

Owner

@adumont commented on GitHub (Mar 18, 2022):

Just tested, --insecure-http-parser switch working for me. Thanks (I do have some sites behind Imperva Incapsula)

@adumont commented on GitHub (Mar 18, 2022): Just tested, --insecure-http-parser switch working for me. Thanks (I do have some sites behind Imperva Incapsula)

deekerman commented

2026-02-28 01:32:14 -05:00

Author

Owner

@henkisdabro commented on GitHub (Apr 15, 2022):

Thanks @simmessa for the solution, much appreciated! Would it be possible to implement some type of "disregard malformed cookies" option on per-monitor level? That way we don't need to make the entire Uptime Kuma instance parse insecure HTTP headers, but rather only when really necessary.

@henkisdabro commented on GitHub (Apr 15, 2022): Thanks @simmessa for the solution, much appreciated! Would it be possible to implement some type of "disregard malformed cookies" option on per-monitor level? That way we don't need to make the entire Uptime Kuma instance parse insecure HTTP headers, but rather only when really necessary.

deekerman commented

2026-02-28 01:32:14 -05:00

Author

Owner

@mitin20 commented on GitHub (Jun 5, 2022):

works perfectly behind imperva-incapsula sites using docker thanks!!! @simmessa @adumont

BTW any idea how to include --insecure-http-parser on kubernetes manifest

@mitin20 commented on GitHub (Jun 5, 2022): works perfectly behind imperva-incapsula sites using docker thanks!!! @simmessa @adumont BTW any idea how to include --insecure-http-parser on kubernetes manifest

deekerman commented

2026-02-28 01:32:14 -05:00

Author

Owner

@3deep5me commented on GitHub (Jun 9, 2022):

@mitin20 check this spec out on a k8s deployment:

spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: uptime-kuma
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: uptime-kuma
    spec:
      containers: #use this down here
      - command:
        - node
        - --insecure-http-parser
        - server/server.js

@3deep5me commented on GitHub (Jun 9, 2022): @mitin20 check this spec out on a k8s deployment: ``` spec: progressDeadlineSeconds: 600 replicas: 1 revisionHistoryLimit: 10 selector: matchLabels: app: uptime-kuma strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate template: metadata: creationTimestamp: null labels: app: uptime-kuma spec: containers: #use this down here - command: - node - --insecure-http-parser - server/server.js ```

deekerman commented

2026-02-28 01:32:14 -05:00

Author

Owner

@louislam commented on GitHub (Jun 9, 2022):

Using environment variable should be easier in Docker/K8s.

NODE_OPTIONS=--insecure-http-parser

@louislam commented on GitHub (Jun 9, 2022): Using environment variable should be easier in Docker/K8s. `NODE_OPTIONS=--insecure-http-parser`

deekerman commented

2026-02-28 01:32:14 -05:00

Author

Owner

@MrCaringi commented on GitHub (Jul 14, 2022):

Hi there,

for the people coming here for a fix I just wanted to add that if you're running uptime-kuma in docker container and you see this issue (maybe you're unlucky enough to be forced to monitor resources behing incapsula malformed cookies) you can quickly fix by launching the docker container with --insecure-http-parser like this:
docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1 node --insecure-http-parser server/server.js

Thanks it worked for my docker-compose too:

    command:
      - node
      - --insecure-http-parser
      - server/server.js

@MrCaringi commented on GitHub (Jul 14, 2022): > Hi there, > > for the people coming here for a fix I just wanted to add that if you're running uptime-kuma in docker container and you see this issue (maybe you're unlucky enough to be forced to monitor resources behing incapsula malformed cookies) you can quickly fix by launching the docker container with --insecure-http-parser like this: > > ``` > docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1 node --insecure-http-parser server/server.js > ``` Thanks it worked for my docker-compose too: ``` command: - node - --insecure-http-parser - server/server.js ```

deekerman commented

2026-02-28 01:32:14 -05:00

Author

Owner

@bamhm182 commented on GitHub (Oct 19, 2022):

Just chiming in here to say I too would like to see the ability to implement this on a per-monitor level as well.

@bamhm182 commented on GitHub (Oct 19, 2022): Just chiming in here to say I too would like to see the ability to implement this on a per-monitor level as well.

deekerman referenced this issue

2026-02-28 01:50:34 -05:00

Lost every config during update #558

deekerman referenced this issue

2026-02-28 03:53:37 -05:00

Can not make a monotor for the http service on 8000 port #4169