as well as the /manual/ returning docroot/index. Need to look for another
solution. I'm suspecting path_info is possibly broken.
Reverts 1.68, as suggested by Brian Havard.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91479 13f79535-47bb-0310-9956-ffa450edef68
of our brigade - which are in isolation okay. In this situation, they
must be removed by the call to APR_BRIGADE_NORMALIZE.
The way we partition the buckets means that we will never remove the
zero-length bucket from the head - causing an infinite loop. We read only
a single bucket now - previously partition with the blocking reads would
read multiple buckets - but it forced having a defined length which we
agreed was bogus.
Therefore, if we have a zero-length bucket at the head, we would then try
to partition and split at the zero-point of the brigade. That combination
doesn't actually remove the zero-length bucket - it is still there - causing
an infinite loop because we'll never go past the zero-length bucket.
This call was originally present in core_input_filter. I think it might
be better to fix partition/split/etc to eliminate a zero-length bucket
and skip it. But, I'm not 100% sure that needs to happen.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91412 13f79535-47bb-0310-9956-ffa450edef68
If the status code is anything other than SUCCESS for PEEK, it isn't
good. Just return the value.
(I thought it should be this, but I wasn't 100% sure. Peer review == good.)
Submitted by: Will Rowe
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91404 13f79535-47bb-0310-9956-ffa450edef68
Return with APR_EOF if we get EAGAIN.
(Whomever is calling this with PEEK should really be able to handle EOS
bucket rather than relying on error codes.)
Thanks to Greg Ames for pointing out this fubar.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91403 13f79535-47bb-0310-9956-ffa450edef68
not all of the configured ports.
Other points to ponder:
why no log message for the segfault?
similar change would seem to be needed in other MPMs... we
may be adding bogus entries to the poll set
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91399 13f79535-47bb-0310-9956-ffa450edef68
This can happen if there is a partial match between a bad URI and a
file with a variant extention.
ap_sub_req_lookup_dirent has apparently been generating bogus subrequest
URIs for ages, but they used to be ignored. Once we started calling
ap_process_request_internal for all subrequests, they started causing
problems. Make it explicit that rnew->uri is to be ignored for this type
of subrequest.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91375 13f79535-47bb-0310-9956-ffa450edef68
activated. It may be bumpy for a few days, and we have more optimizations
to put in place, but it's time to get this in the developer's test code.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91359 13f79535-47bb-0310-9956-ffa450edef68
I ended up blasting these (intentional) changes as well :(
This finishes up the changes for the new, replacement ap_directory_walk
for testing. This code isn't active yet.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91342 13f79535-47bb-0310-9956-ffa450edef68
doesn't activate that code, I will do so probably by Monday, after more
thorough testing.
Introduces the ap_directory_walk::cache so we can stop wasting tons of
effort in mod_autoindex and other subreq/redirect requests.
This isn't thoroughly tested, I've only stepped through a half dozen
common cases. If you want to play, define REPLACE_PATH_INFO_METHOD.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91340 13f79535-47bb-0310-9956-ffa450edef68
(blocking or not).
apr_brigade_partition would do reading multiple times and that's
not really what we want (so I think).
This may speed up POST requests that were waiting for all of the
data to arrive before returning anything in blocking mode.
Reviewed by: Greg Stein, Ryan Bloom
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91322 13f79535-47bb-0310-9956-ffa450edef68
finite number of bytes (i.e. *readbytes > 0).
ap_brigade_partition does a blocking read. So, what we should do is
apr_bucket_read on the socket for non-blocking. If we get less than
what they asked for, that's okay and we should just return that amount.
If they were non-blocking, we should always be non-blocking.
Ryan, Greg, and others can figure out if ap_brigade_partition should
be tweaked to handle AP_NONBLOCK_READ natively. I'm of a mixed mind,
but this addresses the short term need.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91312 13f79535-47bb-0310-9956-ffa450edef68
is now a required directive, which tells Apache what port to
listen on. The ServerName directive has also been extended
to accept an optional port. If the port is specified to the
ServerName, the server will report that port whenever it
reports the port that it is listening on. This change was
made to ease configuration errors that stem from having a Port
directive, and a Listen directive. In that situation, the server
would only listen to the port specified by the Listen command,
which caused a lot of confusion to users.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91293 13f79535-47bb-0310-9956-ffa450edef68
as the parent request. Also pulls a bunch of notes and code that was
set aside, we don't need this with the other optimizations introduced.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91254 13f79535-47bb-0310-9956-ffa450edef68
after deleting the EOS bucket.
This prevents a seg fault in mod_include when the connection dies. There
doesn't seem to be much point in passing empty brigades in general.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91225 13f79535-47bb-0310-9956-ffa450edef68
suggestions to getting rid of redundant variables, as well as
converting the simple ap_queue_full/ap_queue_empty tests into macros.
This also reinstates the "not_full" condition, which turned out to
be useful afterall in cases where we wanted to prevent the listener
thread from accepting further connections until the worker queue has
room for more.
Submitted by: [Aaron Bannert <aaron@clove.org>]
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91223 13f79535-47bb-0310-9956-ffa450edef68
- substr used in APACHE_MODULE for the help string did not parse correctly
with autoconf 2.50+ so we had to punt there anyway and use AC_HELP_STRING.
- Add APACHE_HELP_STRING define that will call AC_HELP_STRING on 2.50+
(actually not 2.13 - look at the regex call) or do our custom variation
of it. This function can't have any extra spaces or it will be returned
in the help string. So noted. If anyone can figure out how to insert
a line break like 2.50+ does when we go over the 26th column, I'd
appreciate it. I tried and I'm way too tired to figure it out now.
Adding this would greatly simplify two or three HELP_STRING uses.
- Switch all of those annoying WITH and ENABLE functions to use the
APACHE_HELP_STRING. This makes everything consistent now. I've always
had to go through and keep aligning everything every few months or so
because I'm the only one who cares. No more. I refuse to do it any more!
Use APACHE_HELP_STRING or be crucified.
Looks decent with autoconf-2.13 and autoconf-2.52.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91211 13f79535-47bb-0310-9956-ffa450edef68
filter until after we have read the headers. This eliminates the status
hack that was in http_protocol.c and makes it all around better.
server/protocol.c now directly adds HTTP_IN filter - should we create a
specific hook for this? (Could we do this as a post_read_request hook?)
I'm not terribly sure, but let's move it down to the lowest possible
place in ap_read_request. We can change this detail later as we see fit.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91192 13f79535-47bb-0310-9956-ffa450edef68
- Clean up scopes and namings of certain variables
- Add comments about potentially bogus modes
- Consolidate a FOREACH loop into a single brigade_length call
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91191 13f79535-47bb-0310-9956-ffa450edef68
rearranging and rethinking some things. The net result is that the HTTP
filter is now a request filter and is now only responsible for HTTP things.
The core input filter is now responsible for handling all of the dirty work.
Highlights:
- Removes the dechunk filter and merges it with ap_http_filter (aka HTTP_IN).
The dechunk filter was incorrectly handling certain cases (trailers).
- Moves ap_http_filter from a connection filter to a request filter
to support the consolidation above (it needs header info).
- Change support code to allow the http_filter to be a
request filter (how the request is setup initially).
- Move most of the logic from HTTP_IN to CORE_IN (core_input_filter).
HTTP_IN is now only concerned about HTTP things. The core filter
is now responsible for returning data. It is impossible to
consolidate dechunk and http without this because HTTP_IN previously
buffered data. As Greg has suggested, it may make sense to write
some brigade functions that handle input (getline). It should be
fairly trivial to add these. Some of the calls in ap_http_filter
could be switched as well.
This is the original patch as submitted to dev@httpd on Monday, Sep.
24th. Additional comments and some minor tweaks done after that
submission are coming up next. This should allow people who reviewed
the original patch to see what has changed and review them piecemeal.
This test passes all current tests in httpd-test. Please perform
chicken sacrifices to verify that this hasn't blown up your favorite
input.
Reviewed by: Greg Stein, Ryan Bloom, and Cliff Woolley (buckets)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91189 13f79535-47bb-0310-9956-ffa450edef68
If we are *already* a faux URI (i.e. relative file sub req) and we then
make a subrequest from that faux URI to a file in the same directory,
we'd try to build a URI out of the fake URI which leads to the wrong
thing happening somewhere down the line. So, let's just give this
special case a fake URI as well.
OtherBill needs to verify this. He can back it out if he wants. I
don't much care. It's one line and it seems okay...
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91187 13f79535-47bb-0310-9956-ffa450edef68
Eliminate URI-centric phases in ap_process_request_internal() for pure
file subrequests (that don't correspond to URI space.) translate_name
hook and location_walks are skipped for these requests.
Moves the reset of the per_dir_config out of directory_walk into the
internal request processing code, so that resources with alternate
map_to_storage requirements start with clean r->server->lookup_defaults.
Optimizes out the authn/authz of effectively identical subreqests and
redirects, as the sub_req_lookup calls once did. Unlike 1.3, we copy
r->user and r->ap_auth_type from main/prev for the request's reference.
Stop copying the subrequest's r->chunked flag (Rbb assured me it looked
bogus, chunking is on the parent request) and clean out other #if 0'ed
cruft we don't need to refer back to anymore.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91169 13f79535-47bb-0310-9956-ffa450edef68
