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

never remember.


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

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

This is a follow up of http://svn.apache.org/r1752347;
ap_meet_conditions could return a 412 status that if not
handled causes subsequent bogus reads and wrong messages
logged (like AH01070). After a chat on dev@ the feedback
was to couple HTTP_NOT_MODIFIED with HTTP_PRECONDITION_FAILED,
but any other feedback is welcome.



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

mod_http2: more const goodiness and checks on h2 request creation, less NULL checking while processing

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

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

brigades.

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

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

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

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

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

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

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

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

MSDN documentation states that

    Any unused members of [an OVERLAPPED] structure should always be
    initialized to zero before the structure is used in a function call.
    Otherwise, the function may fail and return ERROR_INVALID_PARAMETER.

Prior to this patch, the internal state left over from previous
overlapped I/O was passed into the next call. It's unclear what effect
this might have, if any. (I have not personally witnessed an
ERROR_INVALID_PARAMETER myself.)

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

Further follow-up to the previous commit: now that we no longer patch a
network bucket into the brigade, we can revert to calling
ap_process_connection() directly instead of duplicating its logic.

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

Follow-up to the prior commit: without an incoming data buffer, the
custom network bucket code is now orphaned and we can remove it
entirely. This has the added benefit that we are no longer using the
internal OVERLAPPED.Pointer field, which is discouraged by the MSDN
docs.

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

The 'data' AcceptFilter optimization instructs Windows to wait until
data is received on a connection before completing the AcceptEx
operation. Unfortunately, it seems this isn't performed atomically --
AcceptEx "partially" accepts the incoming connection during the wait for
data, leaving all other incoming connections in the accept queue. This
opens the server to a denial of service.

Since the fix for this requires a substantial rearchitecture (likely
involving multiple outstanding calls to AcceptEx), disable the 'data'
filter for now and replace it with 'connect', which uses the AcceptEx
interface but does not wait for data.

Users running prior releases of httpd on Windows should explicitly move
to a 'connect' AcceptFilter in their configurations if they are
currently using the default 'data' filter.

Many thanks to mludha, Arthur Ramsey, Paul Spangler, and many others for
their assistance in tracking down and diagnosing this issue.

PR: 59970

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

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

created by overloading 'int fold' (1 or 0) as 'int flags', with the same
value 1 for AP_GETLINE_FOLD (which httpd doesn't use), and a new value
2 for AP_GETLINE_CRLF

Enforce CRLF when HttpProtocolOptions Strict is in force.

Correctly introduces a new t/TEST fail.



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

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

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

and reflecting the current implementation.


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

based on the fact that bad whitespace shall not be permitted
or corrected in any operating mode, while preserving the 
ability to extract bad method/uri/proto for later reporting
and diagnostics.

This change causes badwhitespace in the request line or any
request field line to always fail, and not honor the setting
of the HttpProtocolOptions Unsafe option. Mult SP characters
or trailing SP characters in the request line are still 
permitted in Unsafe mode.

Adjusted several error message emits to match these changes.



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

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

This choice is unanimous, although StrictURI (a different RFC) still hasn't
found absolute concensus.

An ap_mmn bump will follow (major, this removes a struct elt)



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

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

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

In some cases, a 2nd CGI using the same c->id can get into
the mod_cgid handler before cleanups have been run, causing
the new CGI pid to be used by the first CGI's cleanup function.

Instead of stashing c->id in the request processing thread,
just use it before leaving the handler to get the pid.

May indirectly fix PR57771, but it must have a slightly different
cause because stashing the conn_id slightly differently was 
supposed to be sufficient there.



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

Added William and Jacob to the list of authors to reflect
their participation and suggestions given in the dev@'s email thread (thanks!).



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

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

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

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

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

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

Drop the second reporting of HEAD over HTTP/0.9 requests, we short-circuit
this early now in read_request_line() when presented anything other than
the sole "GET" method permitted by spec.



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

level, no louder. This patch intentionally dodges the Limit* constrained tests
since administrators may shoot themselves in the foot, or be confronted with
impossibly long cookie values, etc.

Adjust the documentation to match.



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

per http://httpd.apache.org/docs/2.4/mod/mod_rewrite.html#comment_5728

split list of flags out of the massive CondPattern list.



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

the admins about Last-Modified header violations rather than trying
to interpret datestrings (like the ones not in GMT).

I also added explicit comments to summarize the current assumptions,
so it will be easier for somebody in the future to modify the code.

The following use cases are covered:
1) (F)CGI backend sends a Last-Modified header not in GMT and considered in the future by httpd (like now() in the EU/Paris timezone)
2) (F)CGI backend sends a Last-Modified header not in GMT and not considered in the future by httpd (like now() + 2 hours in the PST timezone)
3) (F)CGI backend sends a Last-Modified header in GMT but with a datetime in the future

Suggestions and opinion are really welcome.



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

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