httpd

Checkout Tools
  • last updated 3 hours ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates

Changeset 1837178 is being indexed.

updated spanish revision to match English Revision: 1807765 index file
Updated to match English revision 1834263 added the hints secction to spanish
Rebuild.

XML update.

Rebuild.

XML updates.

Rebuild.

XML updates.

core: set ap_request_core_filter() last.

Since it may retain data and should run after other "request" filters, use

the last possible position for a "request" filter: AP_FTYPE_CONNECTION - 1.

mod_ratelimit: Don't interfere with "chunked" encoding.

By the time ap_http_header_filter() sends the header brigade and adds the

"CHUNK" filter, we need to garantee that the header went through all the

filters' stack, and more specifically above ap_http_chunk_filter() which

assumes that all it receives is content data.

Since rate_limit_filter() may retain the header brigade, make it run after

ap_http_chunk_filter(), just before AP_FTYPE_CONNECTION filters.

Also, ap_http_header_filter() shouldn't eat the EOS for HEAD/no-body responses.

For instance mod_ratelimit depends on it since r1835168, but any next request

filter may as well to flush and/or bail out approprietely.

This fixes the regression introduced in 2.4.34 (r1835168).

PR 62568.

missing english rev-1779744 from line 274 to end everything else updated, will be added in next commit
missing english rev-1779744 from line 274 to end every thin else updated, will be added in next commit
rebuild html file

updated translation to match EN-rev 1826856.
Backported in 2.4.34.
http: Enforce consistently no response body with both 204 and 304 statuses.

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.

mod_proxy_http: follow up to r1836588: nonblocking read for 100-continue body.

Set nonblocking read (req->flushall) when handling 100-continue since no body

is expected to be there already.

updated line that has been added on English revision file
xform

Merge r1836758 from trunk:

replace mystery smart-quotes copy/pasted from httpd.conf + vi.

xform

replace mystery smart-quotes copy/pasted from httpd.conf + vi.

mod_proxy_http: follow up to r1836588: fix drop of spurious 100 responses.

r1836588 broke t/security/CVE-2008-2364.t by forwarding more than one

"100 continue" response, fix it.

mod_proxy_http: follow up to r1836588/r1836648: handle unread 100-continue.

When the backend responds with a non-interim response to a 100-continue,

mod_proxy_http won't read the client's body, so make sure "Connection: close"

ends up being added to the response if nobody reads that body later.

The right thing to do at mod_proxy level, rather then forcing AP_CONN_CLOSE,

is to restore r->expecting_100 so that further processing (like error_override

or trying on the next balancer member) can still work.

clean up sandbox, touch mod_proxy.xml, rebuild.

xforms

expand on ProxyPassReverse args

split up the two arguments into their own paragraphs

try to reinforce that the 2nd arg has to match the response

hedaer, and what the first one is used for.

mod_proxy_http: follow up to r1836588: avoid 100-continue responses from core.

When mod_proxy_http handles end-to-end "100 continue", it can't let

ap_http_filter() send its own interim response whenever the body is read.

So save/restore r->expecting_100 before/after handling the request, and use

req->expecting_100 internally (including to restore r->expecting appropriately).

While at it, add comments and debug logs about 100 continue handling, and

fill in missing APLOGNO()s from r1836588.

Merge r1836638 from trunk:

add 2 conditional logging examples

xform