IBM Support

PM78087: IBM HTTP SERVER HIGH MEMORY USE WHEN MANY HUNDREDS OF REWRITECOND %{REQUEST_URI}

Fixes are available

8.5.0.2: WebSphere Application Server V8.5 Fix Pack 2
8.0.0.6: WebSphere Application Server V8.0 Fix Pack 6
7.0.0.29: WebSphere Application Server V7.0 Fix Pack 29
8.0.0.7: WebSphere Application Server V8.0 Fix Pack 7
8.0.0.8: WebSphere Application Server V8.0 Fix Pack 8
7.0.0.31: WebSphere Application Server V7.0 Fix Pack 31
7.0.0.33: WebSphere Application Server V7.0 Fix Pack 33
8.0.0.9: WebSphere Application Server V8.0 Fix Pack 9
7.0.0.35: WebSphere Application Server V7.0 Fix Pack 35
8.0.0.10: WebSphere Application Server V8.0 Fix Pack 10
7.0.0.37: WebSphere Application Server V7.0 Fix Pack 37
8.0.0.11: WebSphere Application Server V8.0 Fix Pack 11
7.0.0.39: WebSphere Application Server V7.0 Fix Pack 39
8.0.0.12: WebSphere Application Server V8.0 Fix Pack 12
7.0.0.41: WebSphere Application Server V7.0 Fix Pack 41
8.0.0.13: WebSphere Application Server V8.0 Fix Pack 13
7.0.0.43: WebSphere Application Server V7.0 Fix Pack 43
8.0.0.14: WebSphere Application Server V8.0 Fix Pack 14
7.0.0.45: WebSphere Application Server V7.0 Fix Pack 45
8.0.0.15: WebSphere Application Server V8.0 Fix Pack 15
7.0.0.29: Java SDK 1.6 SR13 FP2 Cumulative Fix for WebSphere Application Server
7.0.0.45: Java SDK 1.6 SR16 FP60 Cumulative Fix for WebSphere Application Server
7.0.0.31: Java SDK 1.6 SR15 Cumulative Fix for WebSphere Application Server
7.0.0.35: Java SDK 1.6 SR16 FP1 Cumulative Fix for WebSphere Application Server
7.0.0.37: Java SDK 1.6 SR16 FP3 Cumulative Fix for WebSphere Application Server
7.0.0.39: Java SDK 1.6 SR16 FP7 Cumulative Fix for WebSphere Application Server
7.0.0.41: Java SDK 1.6 SR16 FP20 Cumulative Fix for WebSphere Application Server
7.0.0.43: Java SDK 1.6 SR16 FP41 Cumulative Fix for WebSphere Application Server

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • IBM HTTP Server high memory use when many hundreds of
    RewriteCond %{REQUEST_URI} are evaluated and the URL is very
    long.
    
    Typically, only a few conditions will be evaluated per
    request, because RewriteRule is supposed to screen out
    matching URL's. But if many conditions (hundreds) are attached
    to many rules which just pass everything through, a large
    amount of memory will be allocated.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  Users of IBM HTTP Server with many hundreds *
    *                  of RewriteRules that always match and are   *
    *                  accompanied by RewriteCond's containing %   *
    *                  {REQUEST_URI} who are running out of        *
    *                  memory.                                     *
    ****************************************************************
    * PROBLEM DESCRIPTION: Configs with many mod_rewrite           *
    *                      directives can show high mem usage,     *
    *                      requiring MaxMemFree to be set to       *
    *                      avoid OutOfMemory conditions.           *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    mod_rewrite is optimized to short-circuit evaluation of
    RewriteCond when RewriteRules don't match, but some users
    configure catch-all RewriteRules and then rely on RewriteCond
    to do all of the checks.  This is exacerbated by not using the
    [L] flag to stop rewrite processing after a match.
    When hundreds of RewriteConds are evaluated, and they access a
    long URL via %{REQUEST_URI}, those copies of the URL cause the
    thread handling the request to allocate and set aside a lot of
    memory.
    Changing rules and conditions after the fact can be fragile.
    

Problem conclusion

  • A "RewriteOption" sub-option, "NoCopy" was added to allow the
    specific lookup of %{REQUEST_URI} to not cause memory to be
    allocated.  This option is provided as a stop-gap measure when
    MaxMemFree cannot be used or is ineffective, until the ruleset
    can be corrected to not cause the evaluation of many hundreds
    of conditions.
    
    This fix is targeted for IHS fixpacks:
     - 7.0.0.29
     - 8.0.0.6
     - 8.5.0.2
    

Temporary fix

Comments

APAR Information

  • APAR number

    PM78087

  • Reported component name

    IBM HTTP SERVER

  • Reported component ID

    5724J0801

  • Reported release

    700

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2012-11-29

  • Closed date

    2012-12-03

  • Last modified date

    2013-08-01

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    IBM HTTP SERVER

  • Fixed component ID

    5724J0801

Applicable component levels

  • R700 PSY

       UP

  • R800 PSY

       UP

  • R850 PSY

       UP

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTJ","label":"IBM HTTP Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
07 September 2022