Access Gateway Appliance returns 400 "Bad request!" error processing URL with %25 in it

  • 7011672
  • 22-Jan-2013
  • 06-Jun-2013

Environment

NetIQ Access Manager 3.2
NetIQ Access Manager 3.2 Support Pack 1 applied
Access Gateway Appliance and Access Gateway Service both have same issue

Situation

Access Gateway setup to accelerate back end IBM Notes Web server. This IBM Web server generating references to URLs with encoded characters. When the browser issues a HTTP request via the NetIQ Access Gateway with a %25 in the URL, the Proxy responds with a "Bad Request!" error. For example, hits a protected resource with https://nam32app-vm.lab.novell.com/formfill/%25%20tax/, the following error is returned on the browser:

Bad request! Your browser (or proxy) sent a request that this server could not understand.

HTTP headers in response show:

(Status-Line) HTTP/1.1 400 Bad Request
Accept-Ranges bytes
Connection close
Content-Language en
Content-Type text/html; charset=iso-8859-1
Date Tue, 22 Jan 2013 11:12:40 GMT
Server Apache
Vary accept-language,accept-charset

Hitting the https://nam32app-vm.lab.novell.com/formfill/%20%20tax/ works fine (%20 url encoded version of space character).

Note that all works fine with the same URL on the 3.1 Linux Access Gateway Appliance (LAG).

Resolution

Fixed in 3.2 SP2.

There is a workaround that can be used but an time a change is applied to the configuration, the workaround will be lost. With the Apache 2.2 base code Access Manager uses, mod_rewrite added the B flag for this purpose, allowing you to automatically escape backreferences rewritten to your URL. Adding it to your current flag list should fix the problem in that case:
RewriteRule ^.*$ formfill/$0 [B,L]

Apache in it's default mode cannot handle a %25 character in the URL. This %25 character is the URL equivalent of the % character, and the rewriter module chokes and errors out.

When mod_rewrite tests your URLs, they have already been decoded to their natural character format, so in this case %25 has become just %. When you apply this rule to the example above, the backreference actually contains the literal text /formfill/% tax/,, which is not re-encoded by default. Apache has no idea what that % is doing in your request path to/formfill/% tax/, and chokes, giving the error.