Malformed HTTP Header #28

New Issue

Ghost · 2020-01-21T08:55:07Z

Ghost commented

2020-01-21 08:55:07 +00:00

I have multiple instances running on my api server "api.example.com", generated certs successfully for the domain "api.example.com".

But, I access my api instances with a port number like this: api.example.com:5200. This throws a Malformed HTTP Header: 'Host: api.example.com:5200

I Believe this is because of the check in the file https-middleware.js where it deliberately compares hostname with a sanitizeHostname.

Application works fine when I comment out the check, is there a way to allow port numbers on hostnames?

Using "@root/greenlock": "v4"

I have multiple instances running on my api server "api.example.com", generated certs successfully for the domain "api.example.com". But, I access my api instances with a port number like this: api.example.com:5200. This throws a `Malformed HTTP Header: 'Host: api.example.com:5200` I Believe this is because of the check in the file `https-middleware.js` where it deliberately compares hostname with a sanitizeHostname. Application works fine when I comment out the check, is there a way to allow port numbers on hostnames? Using "@root/greenlock": "v4"

coolaj86 commented

2020-02-06 05:18:02 +00:00

Hmm... that's a good question.

Generally it's the job of the reverse proxy to mangle headers.

I realize that I could put an option for this in Greenlock but generally I try to stay away from hacky workarounds to do things the "wrong" way until I understand that there's a darn good reason for it.

What's the use case where you've got port numbers to an https site on purpose?

Hmm... that's a good question. Generally it's the job of the reverse proxy to mangle headers. I realize that I could put an option for this in Greenlock but generally I try to stay away from hacky workarounds to do things the "wrong" way until I understand that there's a darn good reason for it. What's the use case where you've got port numbers to an https site on purpose?

Ghost commented

2020-02-06 05:25:18 +00:00

It's our dev server where we host multiple instances of multiple applications (more than 30). So mapping/unmapping DNS everytime we add/remove an application is a pain.

Also this worked in previous versions of greenlock

It's our dev server where we host multiple instances of multiple applications (more than 30). So mapping/unmapping DNS everytime we add/remove an application is a pain. Also this worked in previous versions of greenlock

Ghost commented

2020-03-12 18:34:02 +00:00

I have the same problem. I need to run a server on a specific port, but the check let the app fail.
Any advice to solve that?

I have the same problem. I need to run a server on a specific port, but the check let the app fail. Any advice to solve that?

Ghost commented

2020-11-10 17:10:24 +00:00

I am getting this same error. App is running inside AWS Beanstalk, sans proxy server / load balancer, direct to a highport >4000. I have it running, but only by commenting out the hostname check in var/app/current/node_modules@root\greenlock-express\https-middleware.js

This raises the obvious problems with maintaining updates, etc.

Has this been addressed in greenlock yet? I've seen some discussion, but no idea if there is now a supported way to use non-standard https ports, regardless the discussion of why I am trying to do it?

I am getting this same error. App is running inside AWS Beanstalk, sans proxy server / load balancer, direct to a highport >4000. I have it running, but only by commenting out the hostname check in var/app/current/node_modules\@root\greenlock-express\https-middleware.js This raises the obvious problems with maintaining updates, etc. Has this been addressed in greenlock yet? I've seen some discussion, but no idea if there is now a supported way to use non-standard https ports, regardless the discussion of why I am trying to do it?

Ghost commented

2021-07-07 10:59:55 +00:00

We have the same issue here.

I don't understand what the problem is of running an app on a different port than 443? The browsers, servers and everything support that, I don't understand why Greenlock would block this?

In our case, it's an API that is only accessible from an app and we specifically don't want to run it on the 443 port.

We have the same issue here. I don't understand what the problem is of running an app on a different port than 443? The browsers, servers and everything support that, I don't understand why Greenlock would block this? In our case, it's an API that is only accessible from an app and we specifically don't want to run it on the 443 port.

Ghost commented

2021-10-07 06:29:55 +00:00

Also same issue here. The problem is that in https-middleware.js safehost doesn't include the port, but hostname does, so the length of safehost is shorter and "Malformed HTTP Heeder" will be returned. I fixed this by removing the port during the check:

        // if there were unallowed characters, complain
        if (safehost.length !== hostname.replace(/:.*/, "").length) {
            res.statusCode = 400;
            res.end("Malformed HTTP Header: 'Host: " + hostname + "'");
            return;
        }

But I wish also that there would be support for different ports, without doing some hotfixes.

Also same issue here. The problem is that in https-middleware.js `safehost` doesn't include the port, but `hostname` does, so the length of `safehost` is shorter and "Malformed HTTP Heeder" will be returned. I fixed this by removing the port during the check: ``` // if there were unallowed characters, complain if (safehost.length !== hostname.replace(/:.*/, "").length) { res.statusCode = 400; res.end("Malformed HTTP Header: 'Host: " + hostname + "'"); return; } ``` But I wish also that there would be support for different ports, without doing some hotfixes.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: root/greenlock-express.js#28