to say about a given set of file extentions (and has only based the
resolved fields on the default language, encoding and content type)
then tell us we can ignore the result by leaving the exception list
entirely undefined. If mod_mime adds anything (a language, charset, or
whatnot) then proceed to use the file in the Multiviews evaluation,
otherwise mod_negotation will ignore the file found.
This points out a need for a slightly twisted DefaultClientLanguage,
as opposed to creating foo.html.html files. Either that, or introduce
a 'neutral' entity that the user can list (say, .default) for mod_mime
to declare it as a fallback language/encoding/content-type/handler.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89919 13f79535-47bb-0310-9956-ffa450edef68
mod_negotiation the 'unresolved' parts of the path in a ->notes
array ap-mime-exceptions-list.
If mod_mime is given index.html.bad.en it will add index and bad
to the list (presuming html and en are both defined.)
mod_negotiation will decide if index and bad are it's fault (the
user requested index.html.bad[.*]) or if it's a messed up file
(say .old, .junk, or .bak).
The next patch to allow any-order negotiation should check each
of these list elements, so that asking for index.bad in the prior
example would succeed. Right now that request would fail because
.html was recognized, so it's not in the exceptions list. This
patch uses a simple strcmp to the given name.
Also, this patch allows any mod_mime processed file to be served,
even if the content type cannot be determined (think README.en).
This is crippled by the client expect headers and omitting the
default content type.
PLEASE vet this code carefully.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89912 13f79535-47bb-0310-9956-ffa450edef68
and have those methods <limit>able in the httpd.conf. It uses
the same bit mask/shifted offset as the original HTTP methods
such as M_GET or M_POST, but expands the total bits from an int to
an ap_int64_t to handle more bits for new request methods than
an int provides.
Submitted by: Cody Sherr <csherr@covalent.net>
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89869 13f79535-47bb-0310-9956-ffa450edef68
reallocation in the merge config phase. Should keep most of the
savings realized by moving to tables.
Need others to vet this code, please! Look at this and the prior
patch as a single diff (-r n -r n-2) to see the overall changes.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89865 13f79535-47bb-0310-9956-ffa450edef68
compliance changes. Note I've left alone the <P> tags, since they
are abused, misused, potentially unsalvageable and certainly more
effort than I care to expend in my quest for brainless end of week
keyboard exercise.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89753 13f79535-47bb-0310-9956-ffa450edef68
header_filter will stay installed in the filter chain when processing
HEAD requests to intercept and discard content bodys sent by poorly
written handlers. This work also points out the need for an optimization
in the content_length filter to not split the brigade if the next bucket
in the brigade is an EOS.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89679 13f79535-47bb-0310-9956-ffa450edef68
where HEAD response headers were being repeated twice for
files greater than 32K bytes (4*AP_MIN_BYTES_TO_WRITE). This
problem in the http_header filter was exposed by the recent rewrite
of the content_length filter.
[Taketo Kabe, Bill Stoddard]
PR: 8037
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89676 13f79535-47bb-0310-9956-ffa450edef68
TLSFilter gets wiped out, breaking any response that comes through ap_die
(including the frequent '304 not modified')
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89601 13f79535-47bb-0310-9956-ffa450edef68
spends a lot of time in apr_table_get calls. Using the default
httpd.conf, the tables for languages and charsets are somewhat
large, so the time spent scanning them on each request is
significant. Replacing the tables with hash tables provides
a nice speedup. [Brian Pane <bpane@pacbell.net>]
Had to handmerge a lot of this patch so please review! Dean had some suggestions
for improvement which are not currently implemented.
Submitted by: Brian Pane
Reviewed by: Bill Stoddard
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89535 13f79535-47bb-0310-9956-ffa450edef68
apr_brigade_puts(). There is still some redundancy--it'd be ideal if there
were an apr_pstrcat() variant that returned the length of the string since
it computes it (twice) anyway so we didn't have to do it yet again. Until
such a beast exists, computing the length three times is better than four.
:-/
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89516 13f79535-47bb-0310-9956-ffa450edef68
Module was calling ap_rwrite() followed by ap_rflush() but the
served content was not being displayed in the browser. Inspection
of the output stream revealed that the first data chunk was
missing the trailing CRLF required by the RFC
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89422 13f79535-47bb-0310-9956-ffa450edef68
* did some code cleanups/optimizations in that function.
* updated Apache's byterange filter to handle the new prototype. added
error handling to the byterange filter should apr_brigade_partition()
ever fail, which it never will unless somebody either removes the earlier
call to apr_brigade_length() for some unknown reason or invents a new
bucket type that is of a predetermined length but which cannot be split
natively (or which has a split that might fail). might as well be
future-proof.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89363 13f79535-47bb-0310-9956-ffa450edef68
contains the correct basic filters when an error occurs. This fixes
a problem where headers are not being sent on error.
PR:
Obtained from:
Submitted by: John Sterling
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89253 13f79535-47bb-0310-9956-ffa450edef68
parms to form_header_field() and it overlaid some vhost structures,
resulting in a segfault in check_hostalias().
[Greg Ames, Jeff Trawick]
Note: Not being familiar with the TRACE method I compared the 2.0
output with 1.3.9 output. The only difference is that with 2.0 we
get a Content-Length header field.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89138 13f79535-47bb-0310-9956-ffa450edef68
again. The problem is that the amount of data read from the network,
is not necessarily the amount of data returned from the filters. It is
possible for input filters to add bytes to the data read from the network.
To fix the original bug, I just removed the line from ap_get_client_block
that decremented r->remaining, we allow the http_filter to do that for
us.
I have also removed an incorrect comment.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89041 13f79535-47bb-0310-9956-ffa450edef68
which corresponded to r->remaining (in ap_get_client_block). However,
ap_get_client_block was *also* adjusting r->remaining. Net result was that
PUT (and probably POST) was broken. (at least on large inputs)
To fix it, I simply removed the indirection on "readbytes" for input
filters. There is no reason for them to return data (the brigade length is
the return length). This also simplifies a number of calls where people
needed to do &zero just to pass zero.
I also added a number of comments about operations and where things could be
improved, or are (semi) broken.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89008 13f79535-47bb-0310-9956-ffa450edef68
determine how much data is returned to the previous filter. Prior to this
change, we used a field in the conn_rec to determine how much to return.
After this change, we use an argument to ap_get_brigade. This makes it
much more obvious how things work at all levels, so that module authors
can easily determine how much data is supposed to be returned to them.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88912 13f79535-47bb-0310-9956-ffa450edef68
mod_log_config has registered an optional function, that other modules
can use to specify a function to be called. This is analogous to the way
that mod_include works. This also allows http to do the connection
logging itself, without exposing HTTP specific pieces to other modules.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88888 13f79535-47bb-0310-9956-ffa450edef68
is definately incorrect. Basically, the first time we call the pre-config
hooks, they are sorted correctly. However, when we call them the second
time, we use the order that modules are loaded into the server. This
move basically puts the http_module after mod_log_config in the compiled
server. It is a hack, and a work-around to allow for my next commit.
When the hook sort issue is solved, this should be re-named to config.m4
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88887 13f79535-47bb-0310-9956-ffa450edef68
request, then the byterange filter should not try to redo the
work. The most common case of this happening, is a byterange
request going through the proxy, and the origin server handles
the byterange request. The proxy should ignore it.
Submitted by: Graham Leggett <minfrin@sharp.fm>
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88873 13f79535-47bb-0310-9956-ffa450edef68
