Bug 107152 - RewriteRule /software/rhea/(.*)$ /software/rha/$1
RewriteRule /software/rhea/(.*)$ /software/rha/$1
Product: Red Hat Web Site
Classification: Red Hat
Component: Other (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Web Development
Web Development
Depends On:
  Show dependency treegraph
Reported: 2003-10-15 10:41 EDT by Vadim Nasardinov
Modified: 2007-04-18 12:58 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-10-22 16:38:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Vadim Nasardinov 2003-10-15 10:41:13 EDT

Quoting from the above post:

For example, requesting


Gets you redirected to:


If we really want to preserve operation of bookmarks, 3rd party links
to our site & search engine indexes, then this should in fact redirect 
to the specific page you originally requested:

Comment 1 Luke Meyer 2003-10-15 15:08:08 EDT
This was implemented this way intentionally -- supposedly due to server load
issues, there may have been other considerations as well.
Comment 2 Vadim Nasardinov 2003-10-15 15:25:01 EDT
Thanks for the response.

I was just curious 

(a) why would
    RewriteRule /software/rhea/(.*)$ /software/rha/$1

    supposedly result in a much higher server load than

    RewriteRule /software/rhea/(.*)$ /software/rha/

(b) what is the contribution of
    http://www.redhat.com/software/rhea/ to the overall
    server load, percentagewise?  Our collective unfounded
    intuition is, it's probably about 1%.  Even if the proposed
    full-blown redirect doubles that number for some unexplained
    reason, the RHEA contribution to the overall servers' workload
    would then be only 2%, hardly a cause for concern.

If anyone has the time to answer either or both of these questions,
their responsiveness would be greatly appreciated.  If not, we'll
just say "tough cheese" and move on.

Thanks again.

Comment 3 Luke Meyer 2003-10-15 15:57:25 EDT
I did some digging and after a little tail-chasing, I think we're straight. 
Ignore my original response, I unthinkingly copied what someone else said.  It
turns out that this was just a miscommunication and the redirect can as easily
keep the tail of the url as lop it off, so I've put in a request to have it
kept.  From here it depends on how well it fits into SOC's schedule to make the
config change, test it, and push it live -- even simple changes like this have
some process around them (part of the reason it is the way it is now), so don't
count on it right away, but it should be on its way.
Comment 4 Vadim Nasardinov 2003-10-15 16:01:17 EDT
Awesome.  Thanks a million.
Comment 5 Vadim Nasardinov 2003-10-22 10:08:52 EDT
Is there a place where one can check on the status
of this thing directly and see if it's moving up
the SOC's task queue?
Comment 6 Luke Meyer 2003-10-22 13:37:27 EDT
Despite our laments, there is not.  However with a bunch of other RHEL3-related
redirects going in today it's likely to get fixed.
Comment 7 Luke Meyer 2003-10-22 16:38:49 EDT
seems to have gone through.  check it out.
Comment 8 Vadim Nasardinov 2003-10-22 16:43:13 EDT
indeed, it has.  thanks again.

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