Http vs https problem

RT Users
1

Hello,

I have got a problem with RT runnig simultaneously on http and https ports.
On the https port we are using WebAuth authentication for internal users,
whereas on http port remains RT-authentication for external users.

With this setting in RT_SiteConfig.pm:

Set($WebPath , “/rt”);
Set($WebBaseURL , “https://rtest2.zcu.cz”);

works everything fine on https, but when I click on several submit button
on http port - e.g. Search (main page) or Update Ticket (in Reply) -
I always get:

“The connection to rtest2.zcu.cz:80 has terminated unexpectedly. Some
data may have been transferred.”

It seems it try to communicate on http port with https protocol. When I
switch settings to:

Set($WebBaseURL , “http://rtest2.zcu.cz”);

then works everything fine on http port, whereas on https I get “Bad
request” with click on the same submit buttons.

I’m using RT 3.6.1 from debian package (stable branch).
Could someone help me to avoid this behavior?

Thanks,
Petr Grolmus
Petr Grolmus

Laboratory for Computer Science
University of West Bohemia
Univerzitni 20, 306 14 Pilsen Tel.: +420 377 632 851
Czech Republic E-mail: indy@civ.zcu.cz

2

Hello,

I have got a problem with RT runnig simultaneously on http and
https ports.
On the https port we are using WebAuth authentication for internal
users,
whereas on http port remains RT-authentication for external users.

With this setting in RT_SiteConfig.pm:

Set($WebPath , “/rt”);
Set($WebBaseURL , “https://rtest2.zcu.cz”);

works everything fine on https, but when I click on several submit
button
on http port - e.g. Search (main page) or Update Ticket (in Reply) -
I always get:

“The connection to rtest2.zcu.cz:80 has terminated unexpectedly. Some
data may have been transferred.”

It seems it try to communicate on http port with https protocol.
When I
switch settings to:

Set($WebBaseURL , “http://rtest2.zcu.cz”);

then works everything fine on http port, whereas on https I get “Bad
request” with click on the same submit buttons.

I’m using RT 3.6.1 from debian package (stable branch).
Could someone help me to avoid this behavior?

We’ve done work on the redirects which I suspect are the issue in 3.6.3.

Best,
Jesse

PGP.sig (186 Bytes)

3

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://:80”- which fails. I doubt this
is the correct way to fix this problem, but after it started working we
kinda lost interest …

.r’

Petr Grolmus wrote:

4

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.On 5/15/07, Robert Long rlong@bluegecko.net 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://:80”- which fails. I doubt this
is the correct way to fix this problem, but after it started working we
kinda lost interest …

.r’

Petr Grolmus wrote:

Hello,

I have got a problem with RT runnig simultaneously on http and https
ports.
On the https port we are using WebAuth authentication for internal
users,
whereas on http port remains RT-authentication for external users.

With this setting in RT_SiteConfig.pm:

Set($WebPath , “/rt”);
Set($WebBaseURL , “https://rtest2.zcu.cz”);

works everything fine on https, but when I click on several submit
button
on http port - e.g. Search (main page) or Update Ticket (in Reply) -
I always get:

“The connection to rtest2.zcu.cz:80 has terminated unexpectedly. Some
data may have been transferred.”

It seems it try to communicate on http port with https protocol. When I
switch settings to:

Set($WebBaseURL , “http://rtest2.zcu.cz”);

then works everything fine on http port, whereas on https I get “Bad
request” with click on the same submit buttons.

I’m using RT 3.6.1 from debian package (stable branch).
Could someone help me to avoid this behavior?

Thanks,
Petr Grolmus

Petr Grolmus

Laboratory for Computer Science
University of West Bohemia
Univerzitni 20, 306 14 Pilsen Tel.: +420 377 632
851
Czech Republic E-mail:
indy@civ.zcu.cz

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

One way or another, everyone stops bleeding.

5

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 rlong@bluegecko.net 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://: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
mikef@ack.Berkeley.EDU 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
Socrates and Berkeley Scholars Web Hosting Services Have Been Retired | Web Platform Services http://ist.berkeley.edu

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBRkp0Bq0bf1iNr4mCEQLpGQCcCz3konAkk/pBeqss5LJMCHuBEs8An2zU
1eroNtFex0rIH8jFzISNZ3Xt
=BMU0
-----END PGP SIGNATURE-----

6

Hello,

it seems neither the upgrade to RT 3.6.3 nor comment out the
line “$uri->port($ENV{‘SERVER_PORT’});” in Web.pm helped at all. The
latter has a really weird behavior :wink: If in RT_SiteConfig.pm is the
version with “https”:

Set($WebBaseURL , “https://rtest2.zcu.cz”);

then on non-https port (after the click on mentioned submit buttons) it
redirects page to https port (but now without an alert :wink: and vice versa…

I tried to make some experiments and I figured out this “hack” that
seems working… in RT/Interface/Web.pm I replaced the line:

$HTML::Mason::Commands::m->redirect($uri->canonical);

with next code:

my $my_redirect = $uri->canonical;
if ($ENV{'SERVER_PORT'} == 80) {
   $my_redirect =~ s/^https/http/;
}
$HTML::Mason::Commands::m->redirect($my_redirect);

It’s really dirty hack… but it’s working with my settings…

Petr Grolmus

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://:80”- which fails. I doubt this
is the correct way to fix this problem, but after it started working we
kinda lost interest …

Petr Grolmus

Laboratory for Computer Science
University of West Bohemia
Univerzitni 20, 306 14 Pilsen Tel.: +420 377 632 851
Czech Republic E-mail: indy@civ.zcu.cz

7

I am running RT 3.6.3 on two systems: An older Linux system using Apache 2
and Apache’s mod_fastcgi module and an FC6 system with Apache 2 and
mod_fcgid (an alternative to the Apache mod_fastcgi module). Both
installations work just fine.

Prior to installing 4.6.4, I upgraded the few Perl modules on each system
that needed it. My RT upgrade process simply consists of installing RT
from scratch then creating softlinks to the new installation - this way I
don’t write over the working, older installation directory.

However, after switching over to 3.6.4 and restarting Apache, I get ‘500
internal server failure’ errors on both machines. On the older system with
Apache’s fast cgi module, I get:

[Wed Jul 11 20:55:58 2007] [error] [client xxx.xxx.xxx.xxx] FastCGI: comm
with server “/opt/rt3/bin/mason_handler.fcgi” aborted: idle timeout (360
sec)
[Wed Jul 11 20:55:58 2007] [error] [client xxx.xxx.xxx.xxx] FastCGI:
incomplete headers (0 bytes) received from server
“/opt/rt3/bin/mason_handler.fcgi”

On the FC6 system with the alternative mod_fcgid module, I get:

[Wed Jul 11
21:54:26 2007]
[warn]
mod_fcgid: read
data timeout in
40 seconds
[Wed Jul 11
21:54:26 2007]
[error] [client
xxx.xxx.xxx.xxx]
Premature end of
script headers:
mason_handler.fc
gi
[Wed Jul 11
21:54:35 2007]
[notice]
mod_fcgid:
process
/opt/rt3/bin/mas
on_handler.fcgi(
20631)
exit(communicati
on error), get
stop signal 15
[Wed Jul 11
21:55:12 2007]
[warn]
mod_fcgid: read
data timeout in
40 seconds
[Wed Jul 11
21:55:12 2007]
[warn]
(110)Connection
timed out:
mod_fcgid:
ap_pass_brigade
failed in
handle_request
function

No MySQL
database changes
have been made.
There is no
mason cache to
clear since I’m
basically
working with new
installations.

Anyone else
encountering
similar
problems?
Swapping back to
3.6.3 works just
fine.

James Moseley