[cgit PATCH] 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 <redacted>
---
 ui-shared.c |   19 ++++++++++++-------
 1 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/ui-shared.c b/ui-shared.c
index 37c60b2..5a848c1 100644
--- a/ui-shared.c
+++ b/ui-shared.c

@@ -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;
 }
 

-- 
Eric Wong

On Mon, Sep 1, 2008 at 8:30 AM, Eric Wong [off-list ref] wrote:

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.

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

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

Lars Hjemli [off-list ref] wrote:

On Mon, Sep 1, 2008 at 8:30 AM, Eric Wong [off-list ref] wrote:

quoted

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 :)

-- 
Eric Wong

On Tue, Sep 2, 2008 at 1:07 AM, Eric Wong [off-list ref] wrote:

Lars Hjemli [off-list ref] wrote:

quoted

On Mon, Sep 1, 2008 at 8:30 AM, Eric Wong [off-list ref] wrote:

quoted

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

Lars Hjemli [off-list ref] wrote:

On Tue, Sep 2, 2008 at 1:07 AM, Eric Wong [off-list ref] wrote:

quoted

Lars Hjemli [off-list ref] wrote:

quoted

On Mon, Sep 1, 2008 at 8:30 AM, Eric Wong [off-list ref] wrote:

quoted

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.

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.

-- 
Eric Wong

On Tue, Sep 2, 2008 at 1:30 AM, Eric Wong [off-list ref] wrote:

Lars Hjemli [off-list ref] wrote:

quoted

On Tue, Sep 2, 2008 at 1:07 AM, Eric Wong [off-list ref] wrote:

quoted

Lars Hjemli [off-list ref] wrote:

quoted

On Mon, Sep 1, 2008 at 8:30 AM, Eric Wong [off-list ref] wrote:

quoted

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.

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