Malformed HTTP Header #28

Open
opened 2020-01-21 08:55:07 +00:00 by Ghost · 6 comments

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"
Owner

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?
Author

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
Author

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?
Author

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?
Author

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.
Author

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.
No Label
No Milestone
No Assignees
2 Participants
Notifications
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: root/greenlock-express.js#28
No description provided.