The error is: "filter-expr(funcall(current, []), [pred(=(step("attribute", 39), literal-expr(section)))])'. Cause: Erreur lors de la vérification du type de l'expression 'filter-expr(funcall(current, []), [pred(=(step("attribute", 39), literal-expr(section)))])"

This takes us 1 step closer to use Ant 1.9+ and remove Xerces and Xalan from the build chain.


Patch tested with the current doc build chain (Ant 1.6.5 + Xerces + Xalan) on the 2.4.x branch.
Even if actually we don't have any "<Foo>" and "Foo" directives, I've checked that the doc is built correctly in such a case.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1854677 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1854409 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1854379 13f79535-47bb-0310-9956-ffa450edef68

     to trigger immediate shutdown of backend connections. This is now always signalled
     by mod_http2 when the the session is being released. 
     proxy_http2 now only sends a PING frame to the backend when there is not already one
     in flight. [Stefan Eissing]

  *) mod_proxy_http2: fixed an issue where a proxy_http2 handler entered an infinite 
     loop when encountering certain errors on the backend connection. 
     See <https://bz.apache.org/bugzilla/show_bug.cgi?id=63170>. [Stefan Eissing]



git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1854365 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1854223 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1854222 13f79535-47bb-0310-9956-ffa450edef68

Don't eat the EOS in ap_http_header_filter() if it comes in single brigade
with a full response to a HEAD request, otherwise mod_ratelimit will never
flush its pending data.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1854004 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1854002 13f79535-47bb-0310-9956-ffa450edef68

cryptographic 

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1854000 13f79535-47bb-0310-9956-ffa450edef68

This is way too verbose (every 100ms) to be logged at any LogLevel.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853992 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853980 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853967 13f79535-47bb-0310-9956-ffa450edef68

No, if we read more bytes than the C-L there is really something wrong in
our (or some) HTTP input filter.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853956 13f79535-47bb-0310-9956-ffa450edef68

Since stream_reqbody_cl() and stream_reqbody_chunked}() now have the same
structure, join them into a single stream_reqbody() function which is passed
the rb_method to handle only CL vs chunked cases differently.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853953 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853938 13f79535-47bb-0310-9956-ffa450edef68

It helps both code readability where stages are initilized and potential
logging in the output filter (even if the stage is disabled).


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853935 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853929 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853908 13f79535-47bb-0310-9956-ffa450edef68

The timeouts apply between the process_connection and pre_read_request hooks.
They are disabled by default for compatibily reasons.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853906 13f79535-47bb-0310-9956-ffa450edef68

With a bit of macro magic, this is to avoid more code duplication when adding
new stages (next commit will add TLS/handshake timeouts handling in addition to
existing header and body ones).

No functional change here.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853901 13f79535-47bb-0310-9956-ffa450edef68

Below some threshold, the previous code tried free (sub-)pooled memory ASAP by
moving small buffers (< capacity / 2) to a heap bucket. But this is not really
an optimization because first it requires at some point to allocate more than
the configured capacity, and second since this happens during response handling
the pool is about to be destroyed soon anymay.

This commit simply keeps the data in the subpool and uses a pool bucket for the
output brigade to take care of the lifetime until it's consumed (or not).


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853874 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853757 13f79535-47bb-0310-9956-ffa450edef68

- Be consistent with the case used for AuthLDAPURL. Use uppercase URL, as in the code in order to fix syntax highlight issues.
- Fix the case of AuthLDAPSubGroupAttribute in <default>, so that quickreference.xsl works as expected

Fix some other small layout issues.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853664 13f79535-47bb-0310-9956-ffa450edef68

+ remove a trailing space to synch with 2.4.x

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853644 13f79535-47bb-0310-9956-ffa450edef68

Always align on the left code in <highlight> block in order to be consistent and fix a layout issue.

Add some links between directives.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853637 13f79535-47bb-0310-9956-ffa450edef68

  default base_dir.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853631 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853624 13f79535-47bb-0310-9956-ffa450edef68

Add some links.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853623 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853618 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853617 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853616 13f79535-47bb-0310-9956-ffa450edef68

Comment-out these tests because of the noise it generates, but leave it there, if useful for s.o.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853615 13f79535-47bb-0310-9956-ffa450edef68

Handle "proxy-sendextracrlf" within the loop too.

Btw, this extra CRLF heresy should go (at least in trunk)


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853566 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853565 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853564 13f79535-47bb-0310-9956-ffa450edef68

It's better/simpler to handle the final 0-size chunk within the loop (on EOS).


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853561 13f79535-47bb-0310-9956-ffa450edef68

PR 60757



git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853560 13f79535-47bb-0310-9956-ffa450edef68

Don't send two final 0-size chunks when the last read brigade is a single EOS.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853518 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853416 13f79535-47bb-0310-9956-ffa450edef68

Since the forwarding of 100-continue (end to end) in r1836588, we depended on
reading all of the requested HUGE_STRING_LEN bytes to avoid the flushes, but
this is a bit fragile.

This commit introduces the new stream_reqbody_read() function which will try a
nonblocking read first and, if it fails with EAGAIN, will flush on the backend
side before blocking for the next client side read.

We can then use it in stream_reqbody_{chunked,cl}() to flush client forwarded
data only when necessary. This both allows "optimal" flushing and simplifies
code (note that spool_reqbody_cl() also makes use of the new function but not
its nonblocking/flush functionality, thus only for consistency with the two
others, simplification and common error handling).

Also, since proxy_http_req_t::flushall/subprocess_env::proxy-flushall are now
meaningless (and unused) on the backend side, they are renamed respectively to
prefetch_nonblocking/proxy-prefetch-nonblocking, and solely determine whether
to prefetch in nonblocking mode or not. These flags were trunk only and may
not be really useful if we decided to prefetch in nonblocking mode in any case,
but for 2.4.x the opt-in looks wise.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1853407 13f79535-47bb-0310-9956-ffa450edef68