I run RT (upgraded to 4.0.15 today), but this is a small issue I’ve
always had with my set up.
I always get the following in my apache errorlogs:
[Fri Jul 26 09:05:14 2013] [warning]: The requested port (80) does NOT
match the configured WebPort (443). Perhaps you should Set($WebPort,
80); in RT_SiteConfig.pm, otherwise your internal links may be broken.
(/usr/local/rt/sbin/…/lib/RT/Interface/Web.pm:1232)
[Fri Jul 26 09:05:14 2013] [warning]: The requested path (/ticket/) does
NOT match the configured WebPath (/ticket). Perhaps you should
Set($WebPath, ‘/ticket/’); in RT_SiteConfig.pm, otherwise your internal
links may be broken. (/usr/local/rt/sbin/…/lib/RT/Interface/Web.pm:1248)
The first one is because RT sits behind a reverse proxy which strips
SSL, therefore WebPort 443 is correct, as is setting the port to 80
locally in the web server configuration. So the warning is wrong in this
case.
The second one seems to be required, rt moans about the configured
WebPath missing the trailing slash, but I seem to remember that I needed
to configure it this way to correctly get the reverse proxy to fix up
the links in responses.
Would be nice to somehow eliminate these warnings from a future release
or RT.
I run RT (upgraded to 4.0.15 today), but this is a small issue I’ve
always had with my set up.
I always get the following in my apache errorlogs:
You should get these once per process startup, yes?
[Fri Jul 26 09:05:14 2013] [warning]: The requested port (80) does
NOT match the configured WebPort (443). Perhaps you should
Set($WebPort, 80); in RT_SiteConfig.pm, otherwise your internal
links may be broken.
(/usr/local/rt/sbin/…/lib/RT/Interface/Web.pm:1232)
[Fri Jul 26 09:05:14 2013] [warning]: The requested path (/ticket/)
does NOT match the configured WebPath (/ticket). Perhaps you should
Set($WebPath, ‘/ticket/’); in RT_SiteConfig.pm, otherwise your
internal links may be broken.
(/usr/local/rt/sbin/…/lib/RT/Interface/Web.pm:1248)
The first one is because RT sits behind a reverse proxy which strips
SSL, therefore WebPort 443 is correct, as is setting the port to 80
locally in the web server configuration. So the warning is wrong in
this case.
The second one seems to be required, rt moans about the configured
WebPath missing the trailing slash, but I seem to remember that I
needed to configure it this way to correctly get the reverse proxy
to fix up the links in responses.
Would be nice to somehow eliminate these warnings from a future
release or RT.
What are you using to reverse proxy?
These warnings imply that you’ve got something which isn’t passing any
headers that we would expect. In particular, if we detect proxying,
we don’t do the second check.
I run RT (upgraded to 4.0.15 today), but this is a small issue I’ve
always had with my set up.
I always get the following in my apache errorlogs:
You should get these once per process startup, yes?
Yes.
What are you using to reverse proxy?
These warnings imply that you’ve got something which isn’t passing any
headers that we would expect. In particular, if we detect proxying,
we don’t do the second check.
I run RT (upgraded to 4.0.15 today), but this is a small issue I’ve
always had with my set up.
I always get the following in my apache errorlogs:
You should get these once per process startup, yes?
[Fri Jul 26 09:05:14 2013] [warning]: The requested port (80) does
NOT match the configured WebPort (443). Perhaps you should
Set($WebPort, 80); in RT_SiteConfig.pm, otherwise your internal
links may be broken.
(/usr/local/rt/sbin/…/lib/RT/Interface/Web.pm:1232)
[Fri Jul 26 09:05:14 2013] [warning]: The requested path (/ticket/)
does NOT match the configured WebPath (/ticket). Perhaps you should
Set($WebPath, ‘/ticket/’); in RT_SiteConfig.pm, otherwise your
internal links may be broken.
(/usr/local/rt/sbin/…/lib/RT/Interface/Web.pm:1248)
The first one is because RT sits behind a reverse proxy which strips
SSL, therefore WebPort 443 is correct, as is setting the port to 80
locally in the web server configuration. So the warning is wrong in
this case.
The second one seems to be required, rt moans about the configured
WebPath missing the trailing slash, but I seem to remember that I
needed to configure it this way to correctly get the reverse proxy
to fix up the links in responses.
Would be nice to somehow eliminate these warnings from a future
release or RT.
What are you using to reverse proxy?
These warnings imply that you’ve got something which isn’t passing any
headers that we would expect. In particular, if we detect proxying,
we don’t do the second check.
OK, but I should still expect the warnings at startup?
I’ve done a packet capture and noted that I have all these headers set:
X-Forwarded-For: (a comma seperated list of IPs, original client and the
squid server)
X-Forwarded-Host: (a hostname matching the proxying host reverse lookup)
X-Forwarded-Server: (a hostname matching the proxying host reverse lookup)
I’m guessing that at startup there have not been any requests, so I will
still get the warnings?
OK, but I should still expect the warnings at startup?
At startup? The same warnings?
I’ve done a packet capture and noted that I have all these headers set:
X-Forwarded-For: (a comma seperated list of IPs, original client and
the squid server)
X-Forwarded-Host: (a hostname matching the proxying host reverse lookup)
X-Forwarded-Server: (a hostname matching the proxying host reverse lookup)
I’m guessing that at startup there have not been any requests, so I
will still get the warnings?
The only one of those of relevance is HTTP_X_FORWARDED_HOST
The port warnings expect to either be able to look at SERVER_PORT or
match a host:port out of the server vars.