Provide AP_STATUS_IS_HEADER_ONLY() helper/macro to check for 204 or 304 and
use it where some special treatment is needed when no body is expected.
Some of those places handled 204 only.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1837056 13f79535-47bb-0310-9956-ffa450edef68
They were superseded by ap_filter_should_yield() and ap_run_in/output_pending()
in r1706669 and had poor semantics since then (we can't maintain pending
semantics both by filter and for the whole connection).
Register ap_filter_input_pending() as the default input_pending hook (which
seems to have been forgotten in the first place).
On the MPM event side, we don't need to flush pending output data when the
connection has just been processed, ap_filter_should_yield() is lightweight and
enough to determine whether we should really enter write completion state or go
straight to reading. ap_run_output_pending() is used only when write completion
is in place and needs to be completed before more processing.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1836364 13f79535-47bb-0310-9956-ffa450edef68
Straightforward for ap_filter_input_pending() since c->data_in_input_filter is
always checked wherever ap_run_input_pending(c) is.
For ap_filter_output_pending(), this allows to set c->data_in_output_filter in
ap_process_request_after_handler() and avoid an useless flush from mpm_event.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1836239 13f79535-47bb-0310-9956-ffa450edef68
ReadBufferSize allows to configure the size of read buffers, for now it's
mainly used for file buckets reads (apr_bucket_file_set_buf_size), but it could
be used to replace AP_IOBUFSIZE in multiple places.
FlushMaxThreshold and FlushMaxPipelined allow to configure the hardcoded
THRESHOLD_MAX_BUFFER and MAX_REQUESTS_IN_PIPELINE from "util_filter.c".
The former sets the maximum size above which pending data are forcibly flushed
to the network (blocking eventually), and the latter sets the number of
pipelined/pending responses above which they are flushed regardless of whether
a pipelined request is immediately available (zero disables pipelining).
Larger ReadBufferSize and FlushMaxThreshold can trade memory consumption for
performances with the capacity of today's networks.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1836032 13f79535-47bb-0310-9956-ffa450edef68
Since it's internal util_filter use, we shouldn't expose it in conn_rec and
can replace it with a pooled brigade provided by ap_reuse_brigade_from_pool().
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1836020 13f79535-47bb-0310-9956-ffa450edef68
Current RETRIEVE_BRIGADE_FROM_POOL macro from "http_request.c" is turned into
a helper and used in ap_request_core_filter().
We will need it in a subsequent commit in "util_filter.c" too.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1836018 13f79535-47bb-0310-9956-ffa450edef68
Read or write of filter's pending data must happen in the same order as the
filter chain, thus we can't use an apr_hash_t to maintain the pending filters
since it provides no garantee on this matter.
Instead use an APR_RING maintained in c->pending_filters, and since both the
name (was c->filters) and the type changed, MAJOR is bumped (trunk only code
anyway so far).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1835640 13f79535-47bb-0310-9956-ffa450edef68
This function, along with ap_make_etag(), is used by the default_handler in
core.c, and in several modules other than builtin mod_http, breaking static
linking and httpdunit tests build.
The move is done by "svn move modules/http/http_etag.c server/util_etag.c".
MMN major bumped, not backportable (as is) to 2.4.x.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1833083 13f79535-47bb-0310-9956-ffa450edef68
It allows to read a line directly from an input filter, in blocking mode
or not. Since no request_rec is needed, a pool may be given.
Existing ap_[r]getline() function are now based off ap_fgetline() by calling:
ap_fgetline(s, n, read, r->proto_input_filters, flags, bb, r->pool);
Will follow up with a new ap_get_mime_headers_*() flavor which can be used by
any filter that needs non-blocking and not necessarily has a request_rec (e.g.
ap_http_filter() to read proxied response trailers).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1829659 13f79535-47bb-0310-9956-ffa450edef68
MMN bump for CONN_STATE_NUM, plus don't consider CONN_STATE_LINGER_* as valid
states returned process_connection (never have been).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1824862 13f79535-47bb-0310-9956-ffa450edef68
This tweaks accept() failure processing by having ap_unixd_accept
pass more errors up, and having the MPM's check against a macro
to see if they are in a whitelist of non ENETDOWN/EMFILE kind
of potential process-wide errors.
Default behavior is still to exit.
edit: MMN bump in 1820099.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1820098 13f79535-47bb-0310-9956-ffa450edef68
incomplete and not backportable, fix it by introducing NOT_IN_DIR_CONTEXT and
restoring NOT_IN_DIR_LOC_FILE to its previous value.
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
Introduces the syntax "%{:<word>:}", borrowed from the <var>'s one, 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" operators, while the new substitution
regexes (like "s/<pattern>/<substitute>/<flags>") may be used to manipulate
strings in place. All this of course available for both string and boolean
expressions.
Tests and doc updates upcoming..
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1810605 13f79535-47bb-0310-9956-ffa450edef68
Provide a convenient function to get module flags, and remove useless
AP_MODULE_HAS_FLAGS checks in the core, core's version is at current MMN.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1809311 13f79535-47bb-0310-9956-ffa450edef68
ap_pbase64decode_strict() adds to the functionality of
ap_pbase64decode() in two ways:
- the length of the decoded buffer is returned, allowing embedded NULLs
to be retained by the caller
- the input string is strictly checked for Base64 validity, including
correct zero-padding at the end of the string
(This was originally added to the httpdunit feature/backport branch in
r1796208, then reverted in r1799376, since it's currently intended for
trunk only.)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1799380 13f79535-47bb-0310-9956-ffa450edef68