Checkout
 

fanf in httpd

my new homepage url

Following taunts from Alfred Perlstein on IRC, use "httpready"

accept filter rather than "dataready" on FreeBSD after 4.1.1-RELEASE

where it works correctly.

Add the correct language tag for interoperation with the Taiwanese

versions of MSIE and Netscape.

PR: 7142

Submitted by: Clive Lin <clive@CirX.ORG>

Add the correct language tag for interoperation with the Taiwanese

versions of MSIE and Netscape.

PR: 7142

Submitted by: Clive Lin <clive@CirX.ORG>

attribution/PR formatting pedantry

Correct a typo in httpd.conf.

Submitted by: Kunihiro Tanaka <tanaka@apache.or.jp>

PR: 7154

Correct a typo in httpd.conf.

Submitted by: Kunihiro Tanaka <tanaka@apache.or.jp>

PR: 7154

Get the correct IP address if ServerName isn't set and we can't

find a fully-qualified domain name at startup.

PR: 7170

Submitted by: Danek Duvall <dduvall@eng.sun.com>

MF 1.3 the fis for the mod_rewrite stupidity.

Get the correct IP address if ServerName isn't set and we can't

find a fully-qualified domain name at startup.

PR: 7170

Submitted by: Danek Duvall <dduvall@eng.sun.com>

WTF did I think I was doing? Pass the correct string pointers to

find_char_in_brackets().

Reported by: Carsten Gaebler <cg@schlund.de>

fix style bugs and note an assumption

fix comment `httpd -h` -> `httpd -L`

Relax the checking of Host: headers so that only character sequences that

are sensitive to the filesystem are rejected, i.e. forward slashes,

backward slashes, and sequences of more than one dot. This supports iDNS

without compromising the safety of mass vhosting.

PR: 6635

Fix the handling of port numbers in Host headers.

Spotted by: coar

cock-up

extra CRLF isn't a problem

Bring forward from 1.3:

I broke mod_rewrite by modifying strings in place when expanding them,

because variable lookups can cause subrequests which cause mod_rewrite

to do its stuff again including an expansion on the same string, which

is then syntactically invalid. So copy the lookup keys somewhere else

before using them in such a way that may cause recursion.

In addition to this, my parser could also be confused by complicated

nested rewrite map expansions like ${map1:${map2:key|dflt}|dflt} so

fix that too by keeping track of {} when looking for |.

PR: 7087

fix a coment for consistency

Fix the previous commit (rev. 1.168 of mod_rewrite.c) which was grievously

broken regarding the declaration and calling of find_char_in_brackets().

I shouldn't try to do things like this so late at night...

Fix the declaration of the module structure in mod_example.

PR: 7095

Submitted by: Gururaj Upadhye <gururaj@enertec.com>

add missing info to last addition

Fix the RFC number mentioned when complaining about a missing

Host: header.

PR: 7079

Submitted by: Alexey Toptygin <alexeyt@wam.umd.edu>

I broke mod_rewrite by modifying strings in place when expanding them,

because variable lookups can cause subrequests which cause mod_rewrite

to do its stuff again including an expansion on the same string, which

is then syntactically invalid. So copy the lookup keys somewhere else

before using them in such a way that may cause recursion.

In addition to this, my parser could also be confused by complicated

nested rewrite map expansions like ${map1:${map2:key|dflt}|dflt} so

fix that too by keeping track of {} when looking for |.

PR: 7087

Fix the RFC number mentioned when complaining about a missing

Host: header.

PR: 7079

Submitted by: Alexey Toptygin <alexeyt@wam.umd.edu>

add a nice upbeat comment near the top

problem gone!

nearly sorted

Rewrite byterange handling so that:

* the syntax is parsed properly

* unsatisfiable requests cause a 416 error

* the API is completely preserved

PR: 6973

Submitted by: fanf, wrowe

Reviewed by: jim, stoddard, trawick, (dirkx, martin)

note that rewrite map expansions work in rewriteconds