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
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.
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
Created attachment 27971 [details] Logic flow The logic flow document and the issue fix.
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)
Also, what is the ServerName of the host? That is its canonical name.
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
"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.
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.
If you want the port in the ServerName to override the port in the host header, set UseCanonicalName to On.
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,
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.
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.
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?
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.