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.
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.
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.
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? 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.
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='')
- C
--
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.
