On Sunday, August 7, 2011, Chris McDonough <chr...@plope.com> wrote: > On Sun, 2011-08-07 at 09:49 +0200, Eric Lemoine wrote: > >> > There's no reason for the Host header to *not* be passed >> > to the backend server, especially if one of the main purposes in life of >> > the Apache server is to be a frontend for the application being proxied >> > to. Having it Off is a poor default, IMO. >> >> How about this case: >> >> The backend server has two virtual hosts, one serving "app1" and the >> other one serving "app2". The proxy server makes "app1 and "app2" >> available at http://proxy.com/app1 and http://proxy.com/app2, >> respectively. In that case you cannot have the proxy pass the Host >> header, because the backend server wouldn't be able to determine if >> the request should be directed to "app1" or "app2". > > It can, at least for some definition of "backend server virtual host". > If the backend server serves up app1 as /app1 and app2 as /app2 > (regardless of the Host header), this proxy server configuration works: > > <VirtualHost *:80> > ServerName www.example.com > RewriteEngine On > RewriteRule ^/(.*) http://appserver:6543/$1 [L,P] > ProxyPreserveHost on > </VirtualHost> > > The above configuration will pass the request off to > http://appserver:6543 with the SCRIPT_NAME+PATH_INFO that came in to > Apache ($1). But the Host header will be the original Host header, so > that when a URL is generated, it will use the host of the proxy instead > of "appserver", which is exactly what you want.
Sure. I was referring to name-based virtual hosts, where Apache determines the virtual host based on the Host header. > > On the other hand, if the above configuration disincludes the > ProxyPreserveHost On setting, any fully-qualified generated URL will be > wrong. > > This doesn't just include URLs generated by Pyramid APIs like route_url, > static_url, and resource_url. It also includes URLs generated by WebOb > (request.application_url, request.url, etc) and any URLs generated by > middleware that depends on HTTP_HOST. Right. I'd rather apply this: "don't generate fully-qualified URLs in your web apps, or you may have trouble running them behind proxies". > > If you don't allow Apache to pass the Host header in such a system, > you'd need to arrange an alternate scheme to set the Host header in such > a configuration (either in middleware, or via Apache Set-Header). I > can't think of a case where it's advantageous to not use > ProxyPreserveHost to send the Host header, and instead to manage the > Host header yourself. Right. > > There are other reasons to munge the environment differently, like if > you're hosting a "folder" inside a traversal-based application at a root > URL. This is solved by setting request headers as per > http://docs.pylonsproject.org/projects/pyramid/1.1/narr/vhosting.html#virtual-root-support. But even that preserves the Host header. > >> This use case doesn't seem so unrealistic to me. > > If, as you've suggested, your solution will be to develop an application > with host-and-port-free URLs rather than to proxy the Host header, is it > really worth talking about? I was just trying to fully understand why you think ProxyPreserveHost always made sense. > If you always generate paths rather than > generating fully qualified URLs, the value of the Host header (or its > presence or absence) is meaningless anyway. Yes. I think that's the best option. > > In the meantime, even without a "static_path" API, I believe you can do > this to get the path of static URLs: > > static_url('mypackage:static/foo.css', request, _app_url='') Good to know. Thank you for the discussion. -- Eric Lemoine Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac, Cedex Tel : 00 33 4 79 44 44 96 Mail : eric.lemo...@camptocamp.com http://www.camptocamp.com -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
