httpd-users mailing list archives

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

  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

    /data/workspaces/ambivalent/pages/either/or

  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
  result?

  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.

Thanks.
----

[1] http://www.socialtext.com/
[2] https://www.socialtext.net/st-rest-docs/index.cgi
[3] An example would be the canonical URI of a page named 'either/or'
    in the workspace 'ambivalent':
      /data/workspaces/ambivalent/pages/either%2For
[4] http://httpd.apache.org/docs/2.0/mod/core.html#allowencodedslashes
[5] I have a patch that fixes ap_unescape_url_keep2f() and can submit
    it.
[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:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message