Lighttpd

It was not "fixed" in 1.4.x; I don't see any good reason to support broken setups like this (the lighttpd2 development branch supports it, but not because I wanted it to - it just happened due to a more powerful config design).

You'll get a lot of broken links if you change the path outside a CGI context (CGI backends can detect what happend, but the next HTTP server can't see the original request). Just use a separate vhost.

Thank you for the reply. It may mean something to those in the know, but sorry, Ive no idea what you mean :-)

If you will help me (with less knowledge) understand a bit better please:

re: "..reason to support broken setups like this .."

- what is the broken set up you refer to; what do you mean by broken setup ?

re: "... but not because I wanted it to...."

- are you of the opinion that when proxying to an application server (which is a normal requirement), that rewriting the url/path before the proxy action is not a wise way to go about it ?

In my usage instance, as I said, I am asking lighttpd to watch for a given path/url and then proxy or hand-off (not CGI) handling that requirement to the backend application server (in my case Jetty [container for eXist-db] ).

re: "...Just use a separate vhost...."

What do you mean please?

I have lighttpd running as one process and jetty/eXist-db running as another, do you mean just address directly to Jetty/eXist rather than proxy to it via Lighttpd mod_proxy ?

Thank you for the extra insight into your response.

stbuehler wrote:

It was not "fixed" in 1.4.x; I don't see any good reason to support broken setups like this (the lighttpd2 development branch supports it, but not because I wanted it to - it just happened due to a more powerful config design).

You'll get a lot of broken links if you change the path outside a CGI context (CGI backends can detect what happend, but the next HTTP server can't see the original request). Just use a separate vhost.

Hello again, please have a read (if you have not) of my earlier reply.

If you could help as requested, I might have a better understanding of good technique and approach.

I thought using a web server (such as Lighttpd) as a 'front end' to an application server was a usual approach.

Any way, your responses to my earlier post would help - and anything else you can spare.
Thank you regards

You shouldn't use rewrites with a mod_proxy backend (or anything else that cannot know the original request url), as otherwise all redirects and links from that backend are quite likely broken.

Simple example:
- You request http://example.com/blog
- the webserver rewrites it to http://example.com/ and sends it to a backend
- the backend emits a link to http://example.com/style.css, because it thinks it lives at http://example.com/ - but it should have been http://example.com/blog/style.css

So usually you should use rewrites only to get a CGI backend handle requests (like rewriting all missing files to /index.php).

stbuehler wrote:

You shouldn't use rewrites with a mod_proxy backend (or anything else that cannot know the original request url), as otherwise all redirects and links from that backend are quite likely broken.

Simple example:
- You request http://example.com/blog
- the webserver rewrites it to http://example.com/ and sends it to a backend
- the backend emits a link to http://example.com/style.css, because it thinks it lives at http://example.com/ - but it should have been http://example.com/blog/style.css

So usually you should use rewrites only to get a CGI backend handle requests (like rewriting all missing files to /index.php).

Ah - I see what you mean.

Are you classing a whole application hosted on Tomcat, or Jetty (or any other application server) similar to a CGI type service in this respect ?

The reason I ask is because I was looking for a way to 'front end' Jetty (as eXist-db container, but it could be Tomcat or anything similar) with Lighttpd - i.e. using Jetty proxied behind Lighttpd.

In that case and bearing in mind your advice, I should simply be using mod_proxy as required and just pointing to the required Jetty server IP and Port ?

e.g. Lighttpd handles https://example.com/applications/library and sends to 127.0.0.1:8080 via mod_proxy.

Jetty running on 127.0.0.1:8080 receives the proxied URL as above and I have to ensure it knows this as its context, rather than the rewritten url I had originally intended (I intended because I do not know how to change the Jetty/eXist-db context which seems to default to '/' or '/exist).

I realise you are not party to the requirements or 'sat here', but does that sound fair enough and more 'correct' to you ?

Thanks for your time to answer - much appreciated.

ok - consider this issue resolved based on contributions above i.e. rewriting not a good idea when proxying.

Ive set everything in Lighttpd to that documented for proxying and will now concentrate on understanding how to set up the application server to handle the proxied request.

psychicwarrior wrote:

e.g. Lighttpd handles https://example.com/applications/library and sends to 127.0.0.1:8080 via mod_proxy.

Jetty running on 127.0.0.1:8080 receives the proxied URL as above and I have to ensure it knows this as its context, rather than the rewritten url I had originally intended (I intended because I do not know how to change the Jetty/eXist-db context which seems to default to '/' or '/exist).

Yes, that is basically the reason why people ask to "fix #164", and why I keep refusing to do so :)

Just for completeness: the solution is to host such applications on a different hostname ("virtual-host": different hostname, same IP), like https://library.applications.example.com/, or to improve the backend to handle the request the way it is.

stbuehler wrote:

.......

Just for completeness: the solution is to host such applications on a different hostname ("virtual-host": different hostname, same IP), like https://library.applications.example.com/, or to improve the backend to handle the request the way it is.

Question: given the application server runs on a different port, is that achieved by wrapping the proxy within a $HTTP["host"] conditional ?

e.g.

 $HTTP["host"] = "library.applications.example.com" 
{   
   proxy.server = (
  "" => (
    "host" => (
      "host" => "127.0.0.1",
      "port" => 8080
    )
   )
  ) 
 }

I'm just a novice in effect, but I can appreciate the value of the points you've made in this thread. Thank you.

Yes, a different port is usually fine, because a backend will usually use the "Host" header to determine its own hostname and port (and https is signaled through X-Forwarded-Proto).

The upcoming lighttpd 1.4.46 provides a new directive proxy.header to allow basic header rewriting (but not body contents) in the proxy.
See 036d3d3d for details.