Skip to contentSkip to conversation

use Host: header to generate cgit_hosturl

PATCH In review Eric Wong 2 participants 6 messages Jun 15, 2016

lore
Share & tools
lore

Eric Wong

author
#0 lore raw

PATCH 1/1 use Host: header to generate cgit_hosturl

I run an instance of lighttpd for cgit behind nginx (nginx doesn't execute CGI). So the port (SERVER_PORT=33333) that lighttpd runs on sends to cgit is different from the standard port 80 that public clients connect to (via nginx).

This was causing the Atom feed URL to show the private port number that lighttpd was running on.

Since the HTTP/1.1 "Host" header includes the port number if running on a non-standard port, it allows non-client-facing HTTP servers to transparently generate public URLs that clients can see.

So use the "Host" header if it is available and fall back to SERVER_NAME/SERVER_PORT for some clients that don't set HTTP_HOST.

Signed-off-by Eric Wong <[email protected]>
---
 ui-shared.c |   19 ++++++++++++-------
 1 files changed, 12 insertions(+), 7 deletions(-)
ui-shared.c +12 -7
index 37c60b2..5a848c1 100644
@@ -38,14 +38,19 @@ char *cgit_hosturl()
 {
 	char *host, *port;
 
-	host = getenv("SERVER_NAME");
-	if (!host)
-		return NULL;
-	port = getenv("SERVER_PORT");
-	if (port && atoi(port) != 80)
-		host = xstrdup(fmt("%s:%d", host, atoi(port)));
-	else
+	host = getenv("HTTP_HOST");
+	if (host) {
 		host = xstrdup(host);
+	} else {
+		host = getenv("SERVER_NAME");
+		if (!host)
+			return NULL;
+		port = getenv("SERVER_PORT");
+		if (port && atoi(port) != 80)
+			host = xstrdup(fmt("%s:%d", host, atoi(port)));
+		else
+			host = xstrdup(host);
+	}
 	return host;
 }
Signature · 1 line
Eric Wong
#1 lore raw
Quoted 5 lines · Eric Wong

I run an instance of lighttpd for cgit behind nginx (nginx doesn't execute CGI). So the port (SERVER_PORT=33333) that lighttpd runs on sends to cgit is different from the standard port 80 that public clients connect to (via nginx).

Quoted 7 lines

This was causing the Atom feed URL to show the private port number that lighttpd was running on.

Since the HTTP/1.1 "Host" header includes the port number if running on a non-standard port, it allows non-client-facing HTTP servers to transparently generate public URLs that clients can see.

This makes a lot of sense, thanks for the detailed description.

Quoted 3 lines

So use the "Host" header if it is available and fall back to SERVER_NAME/SERVER_PORT for some clients that don't set HTTP_HOST.

Maybe it would be better to use a new cgitrc parameter as fallback if the client doesn't provide the "Host" header?

--
larsh

author
#2 lore raw
Quoted 7 lines · Lars Hjemli
Quoted 3 lines · Eric Wong

So use the "Host" header if it is available and fall back to SERVER_NAME/SERVER_PORT for some clients that don't set HTTP_HOST.

Maybe it would be better to use a new cgitrc parameter as fallback if the client doesn't provide the "Host" header?

That sounds a bit hackish to me since HTTP_HOST, SERVER_NAME and SERVER_PORT are all standardized. Anyhow, it's your call :)

Signature · 1 line
Eric Wong
#3 lore raw
Quoted 11 lines · Eric Wong
Quoted 7 lines · Lars Hjemli
Quoted 3 lines · Eric Wong

So use the "Host" header if it is available and fall back to SERVER_NAME/SERVER_PORT for some clients that don't set HTTP_HOST.

Maybe it would be better to use a new cgitrc parameter as fallback if the client doesn't provide the "Host" header?

That sounds a bit hackish to me since HTTP_HOST, SERVER_NAME and SERVER_PORT are all standardized. Anyhow, it's your call :)

I just figured that since SERVER_NAME/SERVER_PORT doesn't work in a setup like the one you described, clients which doesn't provide the "Host" header would never get a correct url. A default value for the "Host" header in cgitrc would work around this issue.

--
larsh

author
#4 lore raw
Quoted 10 lines · Lars Hjemli
Quoted 9 lines · Eric Wong
Quoted 7 lines · Lars Hjemli
Quoted 3 lines · Eric Wong

So use the "Host" header if it is available and fall back to SERVER_NAME/SERVER_PORT for some clients that don't set HTTP_HOST.

Maybe it would be better to use a new cgitrc parameter as fallback if the client doesn't provide the "Host" header?

Quoted 7 lines
Quoted 2 lines

That sounds a bit hackish to me since HTTP_HOST, SERVER_NAME and SERVER_PORT are all standardized. Anyhow, it's your call :)

I just figured that since SERVER_NAME/SERVER_PORT doesn't work in a setup like the one you described, clients which doesn't provide the "Host" header would never get a correct url. A default value for the "Host" header in cgitrc would work around this issue.

Actually, in my situation, the proxy server will unconditionally set a
Host: header before sending the request to the lighttpd backend. Header rewriting/injection is a common feature in HTTP aware proxies.

Signature · 1 line
Eric Wong
#5 lore raw
Quoted 14 lines · Eric Wong
Quoted 13 lines · Lars Hjemli
Quoted 11 lines · Eric Wong
Quoted 7 lines · Lars Hjemli
Quoted 3 lines · Eric Wong

So use the "Host" header if it is available and fall back to SERVER_NAME/SERVER_PORT for some clients that don't set HTTP_HOST.

Maybe it would be better to use a new cgitrc parameter as fallback if the client doesn't provide the "Host" header?

That sounds a bit hackish to me since HTTP_HOST, SERVER_NAME and SERVER_PORT are all standardized. Anyhow, it's your call :)

Quoted 8 lines
Quoted 4 lines

I just figured that since SERVER_NAME/SERVER_PORT doesn't work in a setup like the one you described, clients which doesn't provide the "Host" header would never get a correct url. A default value for the "Host" header in cgitrc would work around this issue.

Actually, in my situation, the proxy server will unconditionally set a
Host: header before sending the request to the lighttpd backend. Header rewriting/injection is a common feature in HTTP aware proxies.

Ok, so if we assume that the "Host" header is only missing if the client didn't specify it and there's no proxy involved, using SERVER_NAME/SERVER_PORT as a fallback should be ok.

Thanks for the patch and explanation.

--
lh