Stefan Eissing [Tue, 28 Nov 2017 15:14:56 +0000 (15:14 +0000)]
On the 2.4.x-mod_md branch:
Merged r1816552 from trunk.
mod_md: v1.0.5, restricting post_config dry run to be more silent and performing
only necessary work for mod_ssl to be also happy with the configuration.
Luca Toscano [Sun, 26 Nov 2017 10:21:16 +0000 (10:21 +0000)]
docs: allow Directive and <Directive> names to co-exist in the same page.
This work was done in trunk to allow the new mod_md's directive
names <ManagedDomain> and ManagedDomain in the same doc page (without
triggering any validate-xml/xhtml error). Subsequently this also helped
for SSLPolicy and <SSLPolicy>. All the aforementioned Directives
have not been backported yet, but these commits are needed behorehand to
allow a smoother backport procedure.
I explicitly reverted the changes to sections.xml for this backport since
they mention the above directives, not yet available in 2.4.x and hence
probably confusing for users.
Building the documentation after these changes yield to a no-op as expected.
I also tried to copy mod_md's documentation from trunk and it renders nicely.
Merge r1805189, r1805193, r1805372, r1805376, r1805189, r1806443 from trunk:
synopsis.xsl: do not render two times the same
directive HTML if more than one
directive share the same name.
This has happened when mod_md.xml was introduced,
and the following directives shared the same name:
* ManagedDomain
* <ManagedDomain>
With the current code each time that a node needs
to be rendered it will emit a duplicate, ending up
in the above example with 4 sections rather than two.
Uniqueness of sections will be ensured by the HTML
elements ids, to avoid errors before committing for
example (accidental duplicates, etc..).
common|synopsis.xsl: rename directive type=sections id generation
This commits is a follow up of r1805189 and it is meant
to allow directives with the same name but different type
to coexist in the same document without triggering errors
while executing validate-xhtml.
For example: mod_md.xml recently introduced the following:
* ManagedDomain
* <ManagedDomain> (this one is type=section)
In my opinion this is a perfectly valid use case and it should
be allowed/handled correctly by the doc generation process/validation.
In order to avoid clashing the directive ids will get a suffix
called "section" if type=section will be present as param.
Quicklinks, <directive> links have been updated to the new
scheme to avoid dandling pointers in the doc.
Comments/reviews are welcome, if I left something behind
please let me know.
doc xsl/dtd: introduce idtype attribute for directivesynopsis
In r1805193 synopsis.xsl was changed to allow two directives
of different type (like <SSLPolicy> and SSLPolicy) to share
the same name but have different ids (and please validate-xml/xhtml).
The downside of this action was that all the quicklinks to
existing directive sections (like <If>, <VirtualHost>, etc..)
were changed, possibly breaking external clients already
referencing them.
This change introduces a new attribute in the directivesynopsis
DTD, namely 'idtype', that will be appended to 'name'
in the id generation by synopsis.xsl. This will rollback
link names to their previous values and will allow documentators
to fine tune directivesynopsis sections as they need
(for example we have recently introduced mod_md's
ManagedDomain/<ManagedDomain>, and modssl's SSLPolicy/<SSLPolicy>).
This approach seems more precise and less invasive to me.
Of course the name of the attribute can be changed later on
to whatever term would fit best, the main concern for me at
the moment is to restore the trunk documentation to its previous
state.
common.dtd: add idtype attribute to directive
This change completes r1805372 and also fixes
links generation for <ManageDomain> and <SSLPolicy>
in sections.xml
synopsis.xsl: do not render two times the same
directive HTML if more than one
directive share the same name.
This has happened when mod_md.xml was introduced,
and the following directives shared the same name:
* ManagedDomain
* <ManagedDomain>
With the current code each time that a node needs
to be rendered it will emit a duplicate, ending up
in the above example with 4 sections rather than two.
Uniqueness of sections will be ensured by the HTML
elements ids, to avoid errors before committing for
example (accidental duplicates, etc..).
synopsis.xsl: fix broken translation builds
This commit is a follow up of r1805189, in which
a new logic was added to allow to repeat a directive
name only if its type is different (like SSLPolicy
and <SSLPolicy>). The change broken french translations
since the $this variable, containing the translated
sections, was not used anymore.
The XPath code could surely be improved, but it seems
more pressing to allow our translators to get back
to their daily work without interference.
build.sh validate-* worked fine, as well as the build.sh fr
translation.
Luca Toscano [Sun, 26 Nov 2017 00:14:09 +0000 (00:14 +0000)]
Sync with trunk the override suggestions for directives in:
mod_authn_socache.xml
mod_logio.xml
mod_ssl.xml
This caused two issues:
1) ./build.sh validate-xhtml failing due to xml validation
failures for the string "Not applicable".
2) weird categories ('none', 'Not applicable', 'None') in
overrides.html that don't make much sense.
Jim Jagielski [Mon, 13 Nov 2017 13:31:33 +0000 (13:31 +0000)]
Merge r1811744 from trunk:
core, mod_rewrite: introduce the 'redirect-keeps-vary' note
to allow proper Vary header insertion when
dealing with a RewriteRule in a directory
context.
This change is an attempt to fix a long standing problem,
brought up while working on PR 58231. Our documentation clearly
states the following:
"If a HTTP header is used in a condition this header is added
to the Vary header of the response in case the condition
evaluates to true for the request."
This is currently not true for RewriteCond/Rules working in
a directory context, since when an internal redirect happens
all the outstanding response headers get dropped.
There might be a better solution so I am looking forward to
hear more opinions and comments. My goal for a delicate change
like this one would be to affect the least amount of configurations
possible, without triggering unwanted side effects.
If the solution is good for everybody tests will be written
in the suite asap.
*) ab: Make the TLS layer aware that the underlying socket is nonblocking,
and use/handle POLLOUT where needed to avoid busy IOs and recover write
errors when appropriate. [Yann Ylavic]
*) ab: Keep reading nonblocking to exhaust TCP or SSL buffers when previous
read was incomplete (the SSL case can cause the next poll() to timeout
since data are buffered already). PR 61301 [Luca Toscano, Yann Ylavic]
Improve mod_proxy_html doc
- add some links and color highligh
- remove some <var> (i.e. italic) around parameters that should be written unmodified (On|Off...)
r1813997 in trunk + some small modifications to synch with trunk
Jim Jagielski [Tue, 17 Oct 2017 18:48:24 +0000 (18:48 +0000)]
Merge r1812263, r1812301 from trunk:
Fix maintainer mode with GCC/Clang.
Setting -Wstrict-prototypes in combination
with -Werror leads to compiler errors during
configure checks (autoconf generates incomplete
prototypes).
Adding -Wno-error=strict-prototypes lets the
compiler tolerate those.
Possible future enhancement: remember such
"configure time only" flags and remove them
from CFLAGS before generating our build time
files (Makefile, config_vars.mk etc.), so that
the full -Werror is in place during building.
Follow up to r1812263.
As suggested by Joe, add --maintainer/debugger-mode's CFLAGS in
NOTEST_CFLAGS to avoid interractions with autoconf's AC_LANG_PROGRAM.
APACHE_ADD_GCC_CFLAG now also forces -Wno-strict-prototypes for -Werror
to work despite AC_LANG_PROGRAM generating this warning by itself.
Submitted by: rjung, ylavic
Reviewed by: ylavic, rjung, jim
Rainer Jung [Tue, 17 Oct 2017 18:38:29 +0000 (18:38 +0000)]
Rephrase comments by Yann in order to hopefully
make the current situation clearer.
I hope the new text is OK for Yann, otherwise I
could revert and add as my own comment.
i think r1812339 should be an integral part of
the mod_journald backport and currently we do not
have any obstacle for the configure.in proposal.
The ap_expr fix was already backported, the
mod_remoteip fix does not apply to the 2.4 code
and the mod_journald fix IMHO should be voted and
applied together with the pending mod_journald
backport.
util_expr_eval.c: In function ‘ap_expr_eval_re_backref’:
util_expr_eval.c:265:63: error: comparison between pointer and zero character constant [-Werror=pointer-compare]
if (!ctx->re_pmatch || !ctx->re_source || *ctx->re_source == '\0' ||
Same committer shipped a release with one well known broken platform within
days of proposing a showstopper for a platform. This specific platform is not
even universally broken, but only for maintainer mode builds, and same has
upvoted a backport which can't compile in maintainer mode. Confused yet?
It might also be why this well-reasoned patch gathered little review, since
it was parked in a more obscure place?
Yann Ylavic [Fri, 13 Oct 2017 08:42:57 +0000 (08:42 +0000)]
Merge r1808746, r1809028 from trunk:
mod_rewrite/core: avoid the 'Vary: Host' header
In PR 58231 is was brought up that httpd adds the
Vary: Host header whenever a condition is set to true
in mod_rewrite or in an <If> block.
The https://tools.ietf.org/html/rfc7231#section-7.1.4
section seems to disallow this use case:
"The "Vary" header field in a response describes "
"what parts of a request message, "
"aside from the method, Host header field, [...]"
I had a chat with the folks in #traffic-server and
they don't see much point in having a Vary: Host header,
plus it was reported that Varnish doesn't like it very
much (namely it does not cache the response when
it sees the header, links of the report in the PR).
I don't see much value in this behavior of httpd so
I am inclined to remove this response header value,
but I'd be glad to get a more experienced opinion.
mod_rewrite,core: avoid Vary:Host (part 2)
This is a follow up of r1808746 after a chat
with Yann on dev@:
- the HTTP:Host variable suffers from the same problem
- the strcasecmp should be used to allow case-sensitive
comparisons.
- in mod_rewrite is less cumbersome and more clean to just
make the Host header check in lookup_header, so it will
be automatically picked up by every part of the code
that uses it. It shouldn't be a relevant overhead for
mod_rewrite.
projects / apache / log