Skip to content
  1. Oct 17, 2017
  3. Oct 16, 2017
  5. Oct 14, 2017
    • Yann Ylavic's avatar
      Follow up to r1812193: really change MMN major. · 45fec95a
      Yann Ylavic authored 
      git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1812197 13f79535-47bb-0310-9956-ffa450edef68
      45fec95a
    • Yann Ylavic's avatar
      Follow up to r1740928: including NOT_IN_PROXY in NOT_IN_DIR_LOC_FILE is both · 45529216
      Yann Ylavic authored 
      incomplete and not backportable, fix it by introducing NOT_IN_DIR_CONTEXT.

Per ap_check_cmd_context(), NOT_IN_DIR_LOC_FILE actually/really means "not in
any directory context", while the definition itself does not include all the
existing directory contexts (e.g. <Limit>, or <Proxy> before r1740928).

This is a bit of a misnomer, at least, so instead of (ab)using it by adding the
missing contexts (in an incompatible way), let's define NOT_IN_DIR_CONTEXT to
really exclude all directory context (i.e. NOT_IN_DIR_LOC_FILE + NOT_IN_LIMIT +
NOT_IN_PROXY) and use it wherever NOT_IN_DIR_LOC_FILE was used.

This is by itself a major MMN bump (modules not compiled with this commit and
having directives checked against NOT_IN_DIR_LOC_FILE won't be caught the same
way by NOT_IN_DIR_CONTEXT in the new ap_check_cmd_context() code), but with the
below change, 2.4.x should work as before:

-   if ((forbidden & NOT_IN_DIR_CONTEXT) == NOT_IN_DIR_CONTEXT) {
+   if ((forbidden & NOT_IN_DIR_LOC_FILE) == NOT_IN_DIR_LOC_FILE) {
        if (cmd->path != NULL) {
            return apr_pstrcat(cmd->pool, cmd->cmd->name, gt,
-                           " cannot occur within directory context", NULL);
+                           " cannot occur within <Directory/Location/Files/Proxy> "
+                           "section", NULL);
        }
        ...
    }



git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1812193 13f79535-47bb-0310-9956-ffa450edef68
      45529216
  7. Oct 13, 2017
  9. Oct 12, 2017
  11. Oct 11, 2017
  13. Oct 10, 2017
  15. Oct 09, 2017
  17. Oct 08, 2017
  19. Oct 06, 2017
  21. Oct 05, 2017
  23. Oct 04, 2017
  25. Oct 03, 2017
  27. Oct 02, 2017
    • Yann Ylavic's avatar
      ap_expr: open string expressions to the <word>. · 92de45cd
      Yann Ylavic authored 
      Introduces the syntax "%{:<word>:}", borrowed from the <var>'s one which is
"%{<var_name>[:<var_function_args>]}" and already allowed in string expressions
and which likewise can be embedded anywhere in a string expression (the same
reserved character ':' gets reused in an unambiguous manner).

This allows the two types of expressions (boolean and string) to now share
fully the same language set, namely: strings, lists, vars, regexes, backrefs,
functions with multiple or complex arguments, and especially combinations
thereof.

Most of them were reserved to boolean expressions only, while complex string
constructions can also benefit to, well, strings. The <word> construct allows
that (say the syntax "%{:<word>:}" looks like a temporary variable constructed
in a string).

Since string expressions may now have to deal with lists (arrays), they also
need a way to produce/extract strings from list and vice versa. This can be
done with the new "join" and "split" ...
      92de45cd