-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 15 May 2007 at 17:01 (-0700), mike wrote:
I also had that issue when migrating to 3.6.3, using mod_rewrite to
redirect http to https, and resolved it in the exact same manner. we
didn't have this issue running the 3.2.x release, but i never bothered
diffing to see when that change was added. i couldn't find any other
way to fix it, and couldn't understand the need to explicitly set the
server port env variable anyways, so i just called it "fixed" and moved
on to my next problem :). The only difference is that in my config, I
set $WebBaseURL to the non-https URL, since we've no need for SSL when
accessing RT from inside the private network.
I had to apply the 'hack' (see below) because I'm running on a virtual app
server where the apache instance that points to RT is at 'localhost' and
the outward-facing apache is a reverse proxy. So the latter listens at
port 443 but the inner one that runs RT uses a high numbered port assigned
to my own apache instance. Until I commented out the 'SERVER_PORT' line,
I got weird results (including a popup error message in Firefox under some
circumstances), no matter what I set $WebPort to).
All of which is to say that I still don't understand the intended use of
$WebPort, which didn't exist in earlier RT releases anyway. I ended up
setting it to 443 (I figured it needed some value), but I overrode its use
by constructing my $WebURL explicitly and commenting out the 'SERVER_PORT'
line in the code as shown below.
Mike
=======================================================================
On 5/15/07, Robert Long <[EMAIL PROTECTED]> wrote:
We ran into that problem as well and we fixed it via this hackish-ness:
in RT/Interface/Web.pm . At around line 194 you will see something that
looks like this:
if ($uri->host eq $server_uri->host &
$uri->port eq $server_uri->port) {
$uri->host($ENV{'HTTP_HOST'});
# $uri->port($ENV{'SERVER_PORT'});
}
Make sure that "$uri->port($ENV{'SERVER_PORT'});" is commented out.
If you look at what the webclient is being told to access, it ends up
being something like "https://<yoursite>:80"- which fails. I doubt
this is the correct way to fix this problem, but after it started
working we kinda lost interest ...
_________________________________________________________________________
Mike Friedman Information Services & Technology
[EMAIL PROTECTED] 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
http://socrates.berkeley.edu/~mikef http://ist.berkeley.edu
_________________________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
iQA/AwUBRkp0Bq0bf1iNr4mCEQLpGQCcCz3konAkk/pBeqss5LJMCHuBEs8An2zU
1eroNtFex0rIH8jFzISNZ3Xt
=BMU0
-----END PGP SIGNATURE-----
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
