Bug 52207 - Upgrade apache version from 2.0.59 to 2.2.12 or above result URL redirection error
Summary: Upgrade apache version from 2.0.59 to 2.2.12 or above result URL redirection ...
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_alias (show other bugs)
Version: 2.2.21
Hardware: PC All
: P2 major (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2011-11-18 08:16 UTC by Vincent Yang
Modified: 2018-11-07 21:08 UTC (History)
0 users



Attachments
Logic flow (29.97 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2011-11-18 23:39 UTC, Vincent Yang
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Yang 2011-11-18 08:16:47 UTC
URL: http://aaa.bbb.com under Load Balance, apache is running both 80 and 1701 ports.
We have the redirect rule: RedirectMatch ^/[\/]?$ /redirect/redirect? and we expect to get: http://aaa.bbb.com/redirect/redirect?
However it actually gives back: http://aaa.bbb.com:1701/redirect/redirect?
1701 is the real server port and it should not show up here.

After workaround in different apache version, we found the issue can be replicated in 2.2.12 and above versions. We also found the issue is in modules/mapper/mod_alias.c and we located at the following codes:
            if (ret[0] == '/') {

                ret = ap_construct_url(r->pool, ret, r);
                ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
                              "incomplete redirection target of '%s' for "
                              "URI '%s' modified to '%s'",
                              orig_target, r->uri, ret);
            }

If we remove this code and recompile apache, apache 2.2.12 or above versions will work in our environment.
I don't know why others do not report the issue, but we are using Cisco ACE as a load balancer, and we know current version 2.0.59 works well. 

Here is the list we tested:

Works                   2.0.59 (in use) 
Works                   2.0.64 
Works                   2.2.3
Works                   2.2.11
Issue                     2.2.12 (need mod_alias.c update, verified)
Issue                     2.2.13 (need mod_alias.c update)
Issue                     2.2.15 (need mod_alias.c update)
Issue                     2.2.19 (need mod_alias.c update)
Issue                     2.2.21 (need mod_alias.c update, verified)
Issue                     2.3.15 (need mod_alias.c update)

Please help on this special case and we want to know:
1.) what the exactly reason we have these pieces of code? what use case?
2.) is it an apache redirection issue or ACE has issue in forwarding?
3.) if it is actually a bug, can we fix it in next release?

Thanks a lot!

--Vincent
Comment 1 Nick Kew 2011-11-18 09:14:28 UTC
Since you've discovered which version changed, you can look in CHANGES to see exactly what changed.  In this case it's a bug fix, from earlier behaviour that was in violation of HTTP.

You appear to have a configuration problem, possibly concerning your canonical hostname.  If you have trouble fixing it, the users list (and other support channels) are there to help.  A bug report might arise out of that process, but this isn't it.
Comment 2 Vincent Yang 2011-11-18 23:38:26 UTC
Hi

CHANGES only show:
  *) mod_alias: check sanity in Redirect arguments.
     PR 44729 [Sönke Tesch <st kino-fahrplan.de>, Jim Jagielski]
https://issues.apache.org/bugzilla/show_bug.cgi?id=44729

  *) mod_alias: Ensure Redirect emits HTTP-compliant URLs.
     PR 44020
https://issues.apache.org/bugzilla/show_bug.cgi?id=44020 

However this does not help us, we don't know why a normal vip:80/443 to realip:1701 and also a normal redirectmatch "RedirectMatch ^/[\/]?$ /dispatcher/dispatcher.do?" can cause problem after version 2.2.12

To make the issue more clear, I attached a document to present the logic flow and our issue "fix" by comment out one of the function in the source code of mod_alias.c

Thanks
Vincent
Comment 3 Vincent Yang 2011-11-18 23:39:10 UTC
Created attachment 27971 [details]
Logic flow

The logic flow document and the issue fix.
Comment 4 Eric Covener 2011-11-19 00:23:56 UTC
What's the value of usecanonicalphysicalport?

What does the vhost serving this request look like?

What's the host header on the request (log %{host}i)
Comment 5 William A. Rowe Jr. 2011-11-19 01:47:33 UTC
Also, what is the ServerName of the host?  That is its canonical name.
Comment 6 Vincent Yang 2011-11-19 02:30:51 UTC
Here is the vHost information:
NameVirtualHost *:1701
<VirtualHost *:1701>
 WebLogicHost [tomcat-ip]
 WebLogicPort 80
 ConnectTimeoutSecs 10
 ConnectRetrySecs 5
 #FileCaching OFF 
 MatchExpression *.do
 MatchExpression *.jsp
 MatchExpression *.php
 MatchExpression *.asp
 MatchExpression *.wbx
 MatchExpression *Servlet*
 MatchExpression *Servlet/*
 MatchExpression sendmail
 MatchExpression TestService
 ErrorLog "|/usr/sbin/rotatelogs /var/httplogs/errorlog_xxx_port1701 86400"
 CustomLog "|/usr/sbin/rotatelogs /var/httplogs/accesslog_xxx_port1701 86400" combined
 Include /www/conf/rewrite.httpd
</VirtualHost>


Here is the ServerName and part of httpd.conf configuration:
ServerName is comment out.

#ServerName new.host.name:80
ServerRoot "/etc/httpd"
DocumentRoot "/www/htdocs"
Listen 80
Listen 1701
User apache
Group apache

ServerAdmin root@localhost
Comment 7 William A. Rowe Jr. 2011-11-19 02:52:38 UTC
"ServerName is comment out."

Well, duh.

Next time pay attention when a bug is closed on you as INVALID and follow
the advise they offer.  C.f. Nick's gracious reply in comment #2.
Comment 8 Vincent Yang 2011-11-19 03:17:27 UTC
We added ServerName and it does not have any affect on the issue.
ServerName web-apache.corp.com:80 and tried ServerName web-apache's ip

The weird thing is it works in prior to 2.2.12 version, we tested it on 2.2.11, 2.2.3, 2.0.64 and 2.0.59 and all works with same configuration file.

Thanks.
Comment 9 Eric Covener 2011-11-19 03:51:21 UTC
If you want the port in the ServerName to override the port in the host header, set UseCanonicalName to On.
Comment 10 Vincent Yang 2011-11-19 04:57:26 UTC
Actually we don't want to use ServerName override the port defined in vhost.

We have 20 ports listening on apache from 1701 - 1720.
We use different VIPs configured in load balance to point different apache ports.
These different VIPs are for different customers.

As I am not a system architecture of our service, I may not exactly present the whole architecture level, but here is an example:

cust.corp.com 
    -CNAME- {LoadBalance 64.xx.xx.8} 
    -LB- {VIP- 64.xx.xx.34:80, 64.xx.xx.34:443} 
    -LB-WS- {Apache- 64.xx.xx.181:1701, 64.xx.xx.181:1702} 
    -vhost- {Tomcat- 64.xx.xx.185:2001, 64.xx.xx.185:2003}

Thanks,
Comment 11 William A. Rowe Jr. 2011-11-19 05:23:22 UTC
If you set ServerName web-apache.corp.com:80, and had not set CanonicalName off,
and the redirect resulted in http://web-apache.corp.com:1701/redirect/redirect
then this is indeed a bug.
Comment 12 Vincent Yang 2011-11-19 05:27:33 UTC
Thanks all for your posts.
After setting the ServerName and enable UseCanonicalName.
ServerName webserver.corp.com:80
UseCanonicalName On

the url will have this redirection:
http://cust.corp.com --> http://websvr.corp.com:1701/dispatcher/dispatcher.do?

this is not what we want, we don't want to present the actual websvr ip or domain name in the url as it should be hidden inside of load balance. I mean we want this kind of redirection:
http://cust.corp.com --> http://cust.corp.com/dispatcher/dispatcher.do?
and this is exactly what version before 2.2.12 does and works.
Comment 13 William A. Rowe Jr. 2011-11-19 20:15:38 UTC
Stupid question, but if you move the statement
  ServerName webserver.corp.com:80
into your <VirtualHost > block (as all documentation and tutorials insist
that you)... does this correct the behavior?
Comment 14 William A. Rowe Jr. 2018-11-07 21:08:43 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.