Skip to content
  1. Feb 20, 1999
  2. Feb 17, 1999
    • Ken Coar's avatar
      · b54368f6
      Ken Coar authored
      	Add conditional logging based upon environment variable existence.
      	Also add RefererIgnore functionality from mod_log_referer to
      	mod_log_config; mod_log_referer and mod_log_agent are now
      	deprecated.  The list of envariables to check is set up as
      	an array even though the current implementation (TAKE23)
      	only handles one; just in case we ever want to do something
      	strange like, 'env=foo,bar,!bag'.
      
      PR:		519, 548, 1351, 1811(?), 3449
      
      
      git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82819 13f79535-47bb-0310-9956-ffa450edef68
      b54368f6
  3. Feb 16, 1999
  4. Feb 14, 1999
  5. Feb 11, 1999
  6. Feb 09, 1999
  7. Feb 06, 1999
  8. Feb 05, 1999
  9. Feb 04, 1999
  10. Jan 28, 1999
  11. Jan 27, 1999
  12. Jan 24, 1999
  13. Jan 22, 1999
  14. Jan 20, 1999
  15. Jan 16, 1999
    • Jim Jagielski's avatar
      Take II of the shell consistancy change. Although I agree that the use · 33e19750
      Jim Jagielski authored
      of '.' is easier on the eyes, 'x' does seem more common and old-dog
      shell programmers kind of expect it. It's also easier to search for in
      vi :)
      
      Some may question why we need to wrap or protect if we are sure that
      the $var isn't null, but it really doesn't cost that much for the
      extra insurance and it stops people from having to shift "mental gears"
      when they run across such statements.
      
      Some may question why even bother with a consistant style... I think
      it's important to write readable code and understandable code and code
      that others can maintain easily. A consistant style, IMO, helps this
      effort. It also just plain looks better :)
      PR:
      Obtained from:
      Submitted by:
      Reviewed by:
      
      
      git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82675 13f79535-47bb-0310-9956-ffa450edef68
      33e19750
  16. Jan 15, 1999
  17. Jan 12, 1999
  18. Jan 10, 1999
  19. Jan 09, 1999
  20. Jan 08, 1999
  21. Jan 06, 1999
  22. Jan 05, 1999
  23. Jan 04, 1999
  24. Jan 02, 1999
  25. Jan 01, 1999
    • Ralf S. Engelschall's avatar
      Two minor enhancements to mod_rewrite: First RewriteRule now also supports the · 75bb8d07
      Ralf S. Engelschall authored
      ``nocase|NC'' flag (as RewriteCond already does for ages) to match case
      insensitive (this especially avoids nasty patterns like `[tT][eE][sS][tT]').
      Second two additional internal map functions `escape' and `unescape' were
      added which can be used to escape/unescape to/from hex-encodings in URLs parts
      (this is especially useful in combination with map lookups).
      
      Submitted by: Magnus Bodin, Ian Kallen
      Integrated and fixed by: Ralf S. Engelschall
      
      
      git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82563 13f79535-47bb-0310-9956-ffa450edef68
      75bb8d07
    • Ralf S. Engelschall's avatar
      ``Oh, by the way: the same procedure as last year? · 3fae2252
      Ralf S. Engelschall authored
        The same procedure as _every_ year, James!''
      
      So, a lot of touched files here, but it's just a tiny harmless patch.
      As every year we bump up the year number in our copyright headers.
      
      1. "199x-1998" => "199x-1999"
      2. "1998"      => "1998-1999"
      
      
      git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82561 13f79535-47bb-0310-9956-ffa450edef68
      3fae2252
    • Ralf S. Engelschall's avatar
      · be3aeea1
      Ralf S. Engelschall authored
      Fix a few minor inconsistencies related to directive scoping
      ============================================================
      
      1. httpd -h
      
      Under "httpd -h" one gets a nice English description in which scope a
      directive can occur. But we talk here only about <Directory> and <Location>,
      although <Files> is treated the same (also with `cmd->override ==
      ACCESS_CONF|OR_ALL'). So I think it's correct to also list <Files>, too.
      
      2. Used scope variants
      
      Currently we have 203 directives and they use the following scopes (the
      numbers in parenthesis gives the number of directives using a particular
      scope):
      
         RSRC_CONF (106)
         RSRC_CONF|ACCESS_CONF (5)
         RSRC_CONF|ACCESS_CONF|OR_ALL (1)            <--
         RSRC_CONF|ACCESS_CONF|OR_AUTHCFG (2)        <--
         ACCESS_CONF (5)
         OR_AUTHCFG (20)
         OR_LIMIT (3)
         OR_OPTIONS (4)
         OR_FILEINFO (21)
         OR_INDEXES (23)
         OR_ALL (13)
      
      This is well spreaded and sounds reasonable. Except for
      the two classes:
      
         RSRC_CONF|ACCESS_CONF|OR_ALL (1)
         RSRC_CONF|ACCESS_CONF|OR_AUTHCFG (2)
      
      The first one is just a syntax overkill. It means only OR_ALL, because OR_ALL
      includes (implicitly) already RSRC_CONF and ACCESS_CONF. So, when we fix
      this to OR_ALL we get:
      
         RSRC_CONF (106)
         RSRC_CONF|ACCESS_CONF (5)
         RSRC_CONF|ACCESS_CONF|OR_AUTHCFG (2)        <--
         ACCESS_CONF (5)
         OR_AUTHCFG (20)
         OR_LIMIT (3)
         OR_OPTIONS (4)
         OR_FILEINFO (21)
         OR_INDEXES (23)
         OR_ALL (14)
      
      The remaining RSRC_CONF|ACCESS_CONF|OR_AUTHCFG is used by two directives:
      UseCanonicalName and ContentDigest. Two not too old directives which were
      added mostly at the same time. They're are implemented the same way.
      But the scope looks incorrect. Why?
      
      First, it's again syntax overkill, ok. We can reduce it to
      RSRC_CONF|OR_AUTHCFG. But when we compare it to all other used scopes, it
      looks very inconsistent. No other of the 203 directives want to be applicable
      in such a non-orthoginal scope: on the first hand inside the AuthConfig scope
      (which means .htaccess under "AllowOverride AuthConfig" plus _INSIDE_ of
      <Directory>/<Location>/<Files> sections in httpd.conf only) and on the other
      hand also in RSRC_CONF (which means _OUTSIDE_ of
      <Directory>/<Location>/<Files> sections in httpd.conf only). Sure, finally
      it's everywhere in httpd.conf plus .htaccess under AuthConfig scope.  But it's
      not intuitive: Directives which want to be applicable in such a total scope
      use OR_OPTIONS, OR_FILEINFO or OR_INDEXES. And when we think about
      UseCanonicalName and ContentDigest we find out that they belongs more to
      Options, XBitHack and CheckSpelling than to any AuthXXXX directives.
      
      So, I propose to change the scope of those two directives to OR_OPTIONS.  It
      makes no big difference, of course. It still is useable everwhere inside
      httpd.conf, but inside .htaccess now under Options instead of AuthConfig.  And
      it both belongs to the more correct group of directives and makes our list of
      used scopes more consistent.
      
      With the above patch be get this consistent scope-list:
      
         RSRC_CONF (106)
         RSRC_CONF|ACCESS_CONF (5)
         ACCESS_CONF (5)
         OR_AUTHCFG (20)
         OR_LIMIT (3)
         OR_OPTIONS (6)
         OR_FILEINFO (21)
         OR_INDEXES (23)
         OR_ALL (14)
      
      When we take into account that _theoretically_ there are a lot more variants
      of these or'ed values are possible, this list is _VERY_ clean. Actually it's
      the most clean variant I can think of (except for the fact that the whole
      mechanism is a horrible mess ;-)...
      
      
      git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82558 13f79535-47bb-0310-9956-ffa450edef68
      be3aeea1
  26. Dec 27, 1998
  27. Dec 18, 1998