httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Liggett" <>
Subject [users@httpd] combining AllowEncodedSlashes, reverse proxy, and apache 1.x
Date Tue, 03 Oct 2006 17:17:57 GMT

  At Socialtext[1], we use, in many installations, Apache 2 (hereafter
  "front end") as a server for static content and a reverse proxy for
  Apache 1 with mod_perl (hereafter "back end").  It recently came up,
  in the course of developing a REST API[2], that we need to be able
  to handle URIs with encoded '/' (%2F) characters in them[3].

  In addition to needing this all to work with Apache 2 acting as a
  front end, it also needs to work in an alternate configuration where
  Apache 1 runs alone.

AllowEncodedSlashes bug

  According to the docs[4],

    Allowing encoded slashes does not imply decoding. Occurrences of
    %2F or %5C (only on according systems) will be left as such in the
    otherwise decoded URL string.

  but it is our experience that if a URL like in [3] is passed to
  Apache 2, it gets passed to the reverse proxy as


  which seems to be a bug.[5]

  In addition to this, I believe it's important not to decode '%25' if
  one has AllowEncodedSlashes turned on, otherwise the URLs
  '/foo/%252F' and '/foo/%2F' become indistinguishable.[6]

  The assorted backports of AllowEncodedSlashes to Apache 1 have these
  bugs as well.

Changed URL decoding behaviour in 2.0.55.

  Prior to 2.0.55, the rewrite rule for our reverse proxy looked like

    RewriteMap escape int:escape
    RewriteRule (.*) http://BACK_END${escape:$1}

  where BACK_END is the back end hostname and port.  This was because
  the URL was getting decoded prior to this rule, and an encoded '%43'
  would become a '?', which would parse incorrectly on the back end.

  As of 2.0.55, this extra decoding seems cleaned up, _except_ for
  '%2F' if AllowEncodedSlashes is on.  That is, the bug described
  above is still present.

  As a result, it seems that if we want standard decode/escape
  sementics on the front-end, we must insist on 2.0.55+.

Do we need all this?

  It would seem that we need patched versions of Apache 2.0.55+ and Apache 1
  as described above to solve the problem in both configurations (with
  and without Apache 2 acting as reverse proxy).  Have we
  overcomplicated the problem?  If so is there a simpler combination
  of configuration, versions, or patches that accomplishes the same

  Have I misunderstood anything above?  Requiring specially patched
  versions of both Apaches is a bit of a hardship, so we want to make
  sure we aren't being super dumb here.


[3] An example would be the canonical URI of a page named 'either/or'
    in the workspace 'ambivalent':
[5] I have a patch that fixes ap_unescape_url_keep2f() and can submit
[6] I have a patch for this behaviour too, but the docs would need to
    be modified if it were to be accepted.
Matt Liggett
Senior Software Engineer
Socialtext, Inc.

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message