https://redmine.lighttpd.net/https://redmine.lighttpd.net/favicon.ico?13667327412018-03-22T04:22:19Zlighty labsLighttpd - Feature #2880: Option to turn off response handling in map-urlpathhttps://redmine.lighttpd.net/issues/2880?journal_id=113962018-03-22T04:22:19Zgstrauss
<ul><li><strong>Category</strong> set to <i>mod_proxy</i></li><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Low</i></li></ul><p>What you're asking for seems to be an option to make things inconsistent.</p>
<p>Why does Gitea need lighttpd to map the url-path in the first place? Either Gitea should work without the url mapping, or it should work with the url mapping. It is unbalanced behavior if Gitea needs request url mapping in one direction, but requires that lighttpd skip the reverse mapping in Set-Cookie path=... in the other direction.</p>
<p>.</p>
<p>My first hunch would be that this behavior in Gitea is to workaround other proxies which did not reverse map the paths in Set-Cookie.</p>
<p>Maybe Gitea needs an option to disable the "?redirect_to=/gitea" logic? Or maybe you can just set "?redirect_to=/" ?</p>
<p>If none of this is an option (and I'd like some evidence, please, if you think that's the case), then I <strong>might</strong> consider adding some logic to skip the remap if in the replacement string to be used is already in the url-path, and that replacement string is more than simply "/". This would potentially cause mysterious problems for other backends that happen to have repeated strings in the url-path and that repetition <strong>is</strong> significant to the url-path.</p> Lighttpd - Feature #2880: Option to turn off response handling in map-urlpathhttps://redmine.lighttpd.net/issues/2880?journal_id=113992018-03-22T20:57:36Zganto
<ul></ul><p>gstrauss wrote:</p>
<blockquote>
<p>What you're asking for seems to be an option to make things inconsistent.</p>
<p>Why does Gitea need lighttpd to map the url-path in the first place? Either Gitea should work without the url mapping, or it should work with the url mapping. It is unbalanced behavior if Gitea needs request url mapping in one direction, but requires that lighttpd skip the reverse mapping in Set-Cookie path=... in the other direction.</p>
</blockquote>
<p>I fully agree with you on this. I guess I'll also need to open an issue regarding this behaviour at Gitea, but I first want to find out, what's the exact problem and how could it be solved.</p>
<p>There are three possible ways how it could work:<br />(1) Gitea is fully working with / only and the url-path remap in Lighttpd would handle the sub-URL transparently. This would mean that Gitea is configured with ROOT_URL=http://example.com/ but accessed via http://example.com/gitea/<br />(2) Gitea handles the sub-URL itself so that Lighttpd would forward the request to /gitea unaltered. ROOT_URL would then be http://example.com/gitea and Gitea must be able to properly handle requests to /gitea.<br />(3) Follow the upstream (Gogs) documentation (which is currently not functional) and set ROOT_URL=http://example.com/gitea while also setting a Lighttpd url-path map. This is what seems to work for (most) other HTTP proxies.</p>
Let's setup and try (1):
<ul>
<li>I'll use again the <code>lighttpd.conf</code> setting as posted initially. I restrict <code>HTTP["url"]</code> on purpose to not accidentally leak any requests without <code>/gitea</code> sub-URL:</li>
<li>Gitea <code>app.ini</code>:<br /><pre>
ROOT_URL=http://example.com/
</pre></li>
<li>Gitea Log (<code>/gitea/</code> was properly mapped to <code>/</code> by Lighttpd):<br /><pre>
[Macaron] 2018-03-22 19:44:59: Started GET / for 192.168.10.12
[Macaron] 2018-03-22 19:44:59: Completed / 200 OK in 11.447484ms
</pre></li>
<li>However, the response contains all resources without <code>/gitea</code> url-path:<br /><pre>
$ curl -v http://example.com/gitea/
* Trying 192.168.10.13...
* TCP_NODELAY set
* Connected to example.com (192.168.10.13) port 80 (#0)
> GET /gitea/ HTTP/1.1
> Host: example.com
> User-Agent: curl/7.59.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=UTF-8
< Set-Cookie: lang=en-US; Path=/gitea/; Max-Age=2147483647
< Set-Cookie: i_like_gitea=e0ae809ed746bb71; Path=/gitea/; HttpOnly
< Set-Cookie: _csrf=N3RX3w8i9NjjbzBeHTvrKllvLPU6MTUyMTc0Nzg5OTY3ODkxNjAzMg%3D%3D; Path=/gitea/; Expires=Fri, 23 Mar 2018 19:44:59 GMT; HttpOnly
< X-Frame-Options: SAMEORIGIN
< Date: Thu, 22 Mar 2018 19:44:59 GMT
< Content-Length: 9350
< Server: lighttpd/1.4.49
<!DOCTYPE html>
<html>
<head data-suburl="">
<meta charset="utf-8">
<meta http-equiv="x-ua-compatible" content="ie=edge">
<title>Gitea: Git with a cup of tea</title>
<meta name="theme-color" content="#6cc644">
<meta name="author" content="Gitea - Git with a cup of tea" />
<meta name="description" content="Gitea (Git with a cup of tea) is a painless self-hosted Git service written in Go" />
<meta name="keywords" content="go,git,self-hosted,gitea">
<meta name="referrer" content="no-referrer" />
<meta name="_csrf" content="N3RX3w8i9NjjbzBeHTvrKllvLPU6MTUyMTc0Nzg5OTY3ODkxNjAzMg==" />
<meta name="_suburl" content="" />
[...]
<link rel="shortcut icon" href="/img/favicon.png" />
<link rel="mask-icon" href="/img/gitea-safari.svg" color="#609926">
<link rel="preload" href="/vendor/assets/font-awesome/css/font-awesome.min.css" as="style" onload="this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/vendor/assets/font-awesome/css/font-awesome.min.css"></noscript>
<link rel="stylesheet" href="/vendor/assets/octicons/octicons.min.css">
[...]
</pre></li>
<li>Gitea has no chance to get this links correctly, as both, the client request as well as the ROOT_URL say / is the url-path.</li>
<li>Lighttpd would need to map all possible page content back to what "should" point to <code>/gitea</code> (e.g. <code>data-suburl=""</code> or <code>_suburl content=""</code>). Not really an option...</li>
</ul>
<p>Let's setup and try (2):</p>
<ul>
<li><code>lighttpd.conf</code> now doesn't contain any <code>proxy.header</code> statements</li>
</ul>
<ul>
<li>Gitea <code>app.ini</code>:<br /><pre>
ROOT_URL=http://example.com/gitea/
</pre></li>
</ul>
<ul>
<li>Gitea Log:<br /><pre>
[Macaron] 2018-03-22 20:16:16: Started GET /gitea/ for 192.168.10.12
[Macaron] 2018-03-22 20:16:16: Completed /gitea/ 404 Not Found in 10.019546ms
</pre></li>
</ul>
<ul>
<li>Here we get a simple 404 from Gitea as it doesn't expect the request to contain <code>/gitea</code> although we said so in the ROOT_URL:<br /><pre>
$ curl -v http://example.com/gitea/
* Trying 192.168.10.13...
* TCP_NODELAY set
* Connected to example.com (192.168.10.13) port 80 (#0)
> GET /gitea/ HTTP/1.1
> Host: example.com
> User-Agent: curl/7.59.0
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Content-Type: text/html; charset=UTF-8
< Set-Cookie: lang=en-US; Path=/gitea; Max-Age=2147483647
< Set-Cookie: i_like_gitea=20f4ff6fc5243d33; Path=/gitea; HttpOnly
< Set-Cookie: _csrf=O9cccehIEjhHDTc7Vp0fDt8ws2M6MTUyMTc0OTc3NjA2MzQ4ODg0Mw%3D%3D; Path=/gitea; Expires=Fri, 23 Mar 2018 20:16:16 GMT; HttpOnly
< X-Frame-Options: SAMEORIGIN
< Date: Thu, 22 Mar 2018 20:16:16 GMT
< Content-Length: 7839
< Server: lighttpd/1.4.49
[...]
<a class="item" href="/gitea/user/login?redirect_to=%2fgitea%2fgitea">
<i class="octicon octicon-sign-in"></i> Sign In
</a>
</pre></li>
</ul>
<ul>
<li>A possible fix here would be, that Gitea would (optionally) need to accept requests to a sub-URL as it is already able to generate proper replies containing the sub-URL. See e.g. the <code>Path=/gitea</code> in the cookie.</li>
<li>A funny thing here that it adds the sub-URL from ROOT_URL to the sub-URL from the request which results in a completely wrong redirect URL after an imaginary login. Seems that various things would need a fix here...</li>
</ul>
<p>Number (3) is the one I described initially:</p>
<ul>
<li><code>lighttpd.conf</code> from the initial description</li>
</ul>
<ul>
<li>Gitea <code>app.ini</code>:<br /><pre>
ROOT_URL=http://example.com/gitea/
</pre></li>
</ul>
<ul>
<li>Gitea Log:<br /><pre>
[Macaron] 2018-03-22 20:25:24: Started GET / for 192.168.10.12
[Macaron] 2018-03-22 20:25:24: Completed / 200 OK in 5.798316ms
</pre></li>
</ul>
<ul>
<li>Now we get the wrong cookie path:<br /><pre>
$ curl -v http://example.com/gitea/
* Trying 192.168.10.13...
* TCP_NODELAY set
* Connected to example.com (192.168.10.13) port 80 (#0)
> GET /gitea/ HTTP/1.1
> Host: example.com
> User-Agent: curl/7.59.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=UTF-8
< Set-Cookie: lang=en-US; Path=/gitea/gitea; Max-Age=2147483647
< Set-Cookie: i_like_gitea=083a01d63cd2dd51; Path=/gitea/gitea; HttpOnly
< Set-Cookie: _csrf=Q1qYjqqOz7eyuONkti580G1WQZ46MTUyMTc1MDMyNDM5ODYwNzUzNw%3D%3D; Path=/gitea/gitea; Expires=Fri, 23 Mar 2018 20:25:24 GMT; HttpOnly
< X-Frame-Options: SAMEORIGIN
< Date: Thu, 22 Mar 2018 20:25:24 GMT
< Content-Length: 9658
< Server: lighttpd/1.4.49
<
<!DOCTYPE html>
<html>
<head data-suburl="/gitea">
<meta charset="utf-8">
<meta http-equiv="x-ua-compatible" content="ie=edge">
<title>Gitea: Git with a cup of tea</title>
<meta name="theme-color" content="#6cc644">
<meta name="author" content="Gitea - Git with a cup of tea" />
<meta name="description" content="Gitea (Git with a cup of tea) is a painless self-hosted Git service written in Go" />
<meta name="keywords" content="go,git,self-hosted,gitea">
<meta name="referrer" content="no-referrer" />
<meta name="_csrf" content="Q1qYjqqOz7eyuONkti580G1WQZ46MTUyMTc1MDMyNDM5ODYwNzUzNw==" />
<meta name="_suburl" content="/gitea" />
[...]
<link rel="shortcut icon" href="/gitea/img/favicon.png" />
<link rel="mask-icon" href="/gitea/img/gitea-safari.svg" color="#609926">
<link rel="preload" href="/gitea/vendor/assets/font-awesome/css/font-awesome.min.css" as="style" onload="this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/gitea/vendor/assets/font-awesome/css/font-awesome.min.css"></noscript>
<link rel="stylesheet" href="/gitea/vendor/assets/octicons/octicons.min.css">
[...]
<a class="item" href="/gitea/user/login?redirect_to=%2fgitea">
<i class="octicon octicon-sign-in"></i> Sign In
</a>
</pre></li>
<li>Other than the cookie <code>Path=</code> the page looks alright on first sight</li>
</ul>
<p>I will search the Gogs/Gitea issues for any hints on how they think about (2) or raise an issue there if I can't find anything. Still I also think that (3) should somehow be possible with Lighttpd as that's what people know from other proxies.</p>
<p>Regarding the response remapping: <br />My current understanding is that you remap the path in HTTP headers and Cookies correct? Somehow the documentation about the cookie handling is missing... <br />I understand that auto-detecting if a string should be replaced or not how you describe it might result in unexpected behaviour. But an intentional configuration knob to skip response mapping shouldn't be too scary, or do I miss something?</p> Lighttpd - Feature #2880: Option to turn off response handling in map-urlpathhttps://redmine.lighttpd.net/issues/2880?journal_id=114002018-03-22T23:51:34Zgstrauss
<ul></ul><blockquote><blockquote>
<p>What you're asking for seems to be an option to make things inconsistent.</p>
<p>Why does Gitea need lighttpd to map the url-path in the first place? Either Gitea should work without the url mapping, or it should work with the url mapping. It is unbalanced behavior if Gitea needs request url mapping in one direction, but requires that lighttpd skip the reverse mapping in Set-Cookie path=... in the other direction.</p>
</blockquote></blockquote>
<blockquote>
<p>I fully agree with you on this. I guess I'll also need to open an issue regarding this behaviour at Gitea</p>
</blockquote>
<p>Yes. Add some config to Gitea to disable it's obtuse behavior. Why shouldn't any webapp either require that it be rooted at '/' or be able to handle being located under a configured url-path? (without requiring contortions from the web server)</p>
<p>Given the above, your suggestion that "an intentional configuration knob [in lighttpd] to skip response mapping shouldn't be too scary" is entirely unconvincing. lighttpd should not add sloppy code with inconsistent behavior to work around limitations in a poorly written webapp.</p>
<p>.</p>
<blockquote>
<p>My current understanding is that you remap the path in HTTP headers and Cookies correct? Somehow the documentation about the cookie handling is missing...</p>
</blockquote>
<p><a class="wiki-page" href="https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModProxy">Docs_ModProxy</a><br /><pre>
proxy.header (since 1.4.46) is a list of options to perform simple prefix matching to remap host and URL paths in proxied HTTP headers (commit 036d3d3d)
</pre><br />Set-Cookie is an HTTP header.</p> Lighttpd - Feature #2880: Option to turn off response handling in map-urlpathhttps://redmine.lighttpd.net/issues/2880?journal_id=114012018-03-23T00:59:18Zgstrauss
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Wontfix</i></li></ul><p>I took a very quick look at <a class="external" href="https://github.com/go-gitea/gitea">https://github.com/go-gitea/gitea</a> and might suggest that instead of using setting.AppSubURL all over the place, that the locations which call ctx.SetCookie or assign SessionConfig.CookiePath should use a new value from setting.*, e.g. setting.CookiePath, and that setting.CookiePath default to setting.AppSubURL unless otherwise defined in the config. That might be a quick hack to workaround gitea getting repeated paths in Set-Cookie when used with lighttpd mod_proxy proxy.header map-urlpath.</p>
<p>A better solution would to modify gitea to avoid needing map-urlpath. After all, gitea already needs to be configured to know the "subURL" to generate proper links, since it is specifying URL root-relative links instead of using relative links in body content.</p>