The Perl Toolchain Summit needs more sponsors. If your company depends on Perl, please support this very important event.
 / 
Apache-HeavyCGI-0.013302
River stage zero No dependents
++
/ Apache::HeavyCGI::UnmaskQuery

NAME

Apache::HeavyCGI::UnmaskQuery - Allow queries without a questionmark

SYNOPSIS

  <Perl>
  require Apache::HeavyCGI::UnmaskQuery;
  $PerlPostReadRequestHandler = "Apache::HeavyCGI::UnmaskQuery";
  </Perl>

 -or-

  PerlModule Apache::HeavyCGI::UnmaskQuery
  PerlPostReadRequestHandler Apache::HeavyCGI::UnmaskQuery

DESCRIPTION

This Apache Handler can be used from apache 1.3 (when post_read_request was introduced) upwards to turn a request that looks like an ordinary static request to the unsuspecting observer into a query that can be handled by the CGI or Apache::Request module or by the $r->args method.

The reason why you might want to do this lies in the fact that many cache servers in use today (1999) are configured wrongly in that they disallow caching of URIs with a questionmark in them. By composing URIs with a semicolon instead of a questionmark, these cache servers can be tricked into working correctly.

Thus this handler replaces the first semicolon in any request for an URI with a questionmark (unless that URI does already contain a questionmark). As this is being done in the very early stage of apache's handling phase, namely in a PerlPostReadRequestHandler, all subsequent phases can be tricked into seeing the request as a query.

Unfortunately the last paragraph is not completely true. Apache 1.3.4 is not allowing %2F (a slash in ASCII) and %00 (a binary 0) in the path section of the HTTP URI, only in the searchoart section. Apparently the URL is parsed before the during read_request....

    Breakpoint 1, 0x80b9d05 in ap_unescape_url ()
    (gdb) bt
    #0  0x80b9d05 in ap_unescape_url ()
    #1  0x80b5a56 in ap_some_auth_required ()
    #2  0x80b5fb0 in ap_process_request ()
    #3  0x80adbcd in ap_child_terminate ()
    #4  0x80add58 in ap_child_terminate ()
    #5  0x80adeb3 in ap_child_terminate ()
    #6  0x80ae490 in ap_child_terminate ()
    #7  0x80aecc3 in main ()
    (gdb) c

So if any parameter needs to contain a slash or a binary 0, we must resort to a different escape method. Now it's turning ridiculous quickly. I believe, this is a bug in apache and must be fixed there. But what if the apche group doesn't listen to us?

Easy answer: don't escape slashes if you want to use this technique. Don't dare to need binary nulls in your parameters. Until it is figured out if apache group sees this as a bug or not.