Bug 455185 - Misleading RedirectMatch in /etc/httpd/conf.d/mailman.conf
Misleading RedirectMatch in /etc/httpd/conf.d/mailman.conf
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: mailman (Show other bugs)
5.0
All Linux
low Severity low
: rc
: ---
Assigned To: Jan Kaluža
qe-baseos-daemons
:
Depends On:
Blocks: 606311
  Show dependency treegraph
 
Reported: 2008-07-13 13:10 EDT by Mark Sapiro
Modified: 2013-04-12 15:48 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 606311 (view as bug list)
Environment:
Last Closed: 2013-03-11 04:40:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mark Sapiro 2008-07-13 13:10:03 EDT
The mailman rpm installs /etc/httpd/conf.d/mailman.conf which contains the
following:
-------------------------------
# Uncomment the following line, replacing www.example.com with your server's
# name, to redirect queries to /mailman to the listinfo page (recommended).

#RedirectMatch ^/mailman[/]*$ http://www.example.com/mailman/listinfo
-------------------------------
While this may be appropriate for installations where all mailman lists are in
the one www.example.com domain, in an installation where there are mailman lists
in multiple virtual domains, a more appropriate redirect is

RedirectMatch ^/mailman[/]*$ /mailman/listinfo

I think this latter redirect should be the default and the one containing scheme
and host should be indicated as only being appropriate if you wish to redirect
say http://other.example.com/mailman to http://www.example.com/mailman/listinfo.
Comment 1 Mark Sapiro 2008-07-13 13:48:31 EDT
I have just seen that this bug appears to be a duplicate of Bug 125396:.  John
Dennis says in a comment to that bug:

<quote>
I would think this would return a redirect to a client that is neither
a properly formed URL nor would it contain the server address
component of the URL which the client needs. Note this is not
redirected internally to the apache server.
</quote>

While the above is true, it is not a problem. The browser issues the original
http GET to Host: www.example.com for path /mailman. It receives the 302
indicating Location: /mailman/listinfo so it issues another GET to the same
host/scheme for path /mailman/listinfo.

It works just the same as an href= in a document. I.e., it could be
href="http://www.example.com/mailman/listinfo", or it could be
href="/mailman/listinfo". It works either way. In fact, depending on Apache's
error documents, it will return a document along with the 302 that might look like

    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">\n
    <html><head>\n
    <title>302 Found</title>\n
    </head><body>\n
    <h1>Found</h1>\n
    <p>The document has moved <a href="/mailman/listinfo">here</a>.</p>\n
    <hr>\n
    <address>Apache/2.2.3 (CentOS) Server at www.example.com Port 80</address>\n
    </body></html>\n
Comment 3 RHEL Product and Program Management 2011-01-11 15:39:40 EST
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 4 RHEL Product and Program Management 2011-01-11 18:05:56 EST
This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.
Comment 5 RHEL Product and Program Management 2011-05-31 09:28:42 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 6 Jan Kaluža 2012-03-07 06:01:57 EST
It should be possible to do it with the current version of httpd in rhel5. Proposing for fastrack, because it's only change in the comment and does not affect actual mailman configuration.
Comment 9 Jan Kaluža 2013-03-11 04:40:34 EDT
I am sorry, but it is now too late in the RHEL-5 release cycle.
RHEL-5.10 (the next RHEL-5 minor release) is going to be the first
production phase 2 [1] release of RHEL-5. Since phase 2 we'll be
addressing only security and critical issues.
This one issue is fixed in RHEL-6 therefore I am closing the bug as
NEXTRELEASE.

[1] https://access.redhat.com/support/policy/updates/errata/

Note You need to log in before you can comment on or make changes to this bug.