anymore because getline() returns < 0 upon EOF.
There are also a few very minor tweaks to getline() -- remove an
unused variable, remove a couple of unnecessary comments, simplify
an error path.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86553 13f79535-47bb-0310-9956-ffa450edef68
to follow. This code works for browser based requests and line-based
telnet requests. It is untested with character-based telnet requests.
I will be testing that very soon.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86549 13f79535-47bb-0310-9956-ffa450edef68
currently, but it is a step in the right direction. Input filtering
should be slowly improving from here on out.
Submitted by: Greg Ames, Ryan Bloom, Jeff Trawick
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86547 13f79535-47bb-0310-9956-ffa450edef68
instead of bucket->destroy(). bucket->destroy() wasn't being
called correctly and also we were leaking the storage for the
bucket itself since bucket->destroy() doesn't free the ap_bucket.
Submitted by: Ryan Bloom, Jeff Trawick
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86544 13f79535-47bb-0310-9956-ffa450edef68
this is not the change to allow us to read broken-up header lines again :(
. http_filter()
- respect apr_status_t as set by bucket->read() or ap_get_brigade()
- return apr_status_t instead of length
. ap_get_client_block()
- remove a confusing line which set the length parameter before
- passing it to bucket->read()
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86517 13f79535-47bb-0310-9956-ffa450edef68
sense anymore, because the BUFFs that Apache used to use it for have all
been replaced with buckets. BUFFs can't be used with filters, and Apache
doesn't use these functions anywhere anymore, so they need to go away now.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86439 13f79535-47bb-0310-9956-ffa450edef68
is a step in the right direction. The idea is that the http_filter knows
about the http protocol. So, it uses that knowledge to discover HTTP
request headers, and sends those headers up to getline. However, it keeps
the request body saved in it's ctx pointer.
Later, when ap_get_client_block is called, we have set the remaining field
in the conn_rec. This tells the http_filter how much of the remaining
data is request body, and how much isn't. So, the http_filter can return
the request body unparsed up throught ap_get_client_block.
This doesn't even try to work with chunked input data, and there are still
some other bugs in it, but it works for small-ish files in my tests, and
it lets other people play with the concept of input filters. I will try
to play with this more, but others should feel free to hack around in it
too.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86426 13f79535-47bb-0310-9956-ffa450edef68
is that the bucket code does not respect the length passed into it. This
is correct for buckets, but it means that when we get data out of the
buckets, we may have to split the bucket to make sure that any copy
operations are safe. We were originally doing the split at the number of
characters read from the bucket, but we really want to do it at the length
of the buffer.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86415 13f79535-47bb-0310-9956-ffa450edef68
replacing the majority of fallible rv == APR_condition tests. But there
are lots more to fix, these are the obvious ones that already did proper
canonical error conversion.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86405 13f79535-47bb-0310-9956-ffa450edef68
1) separate filter lists hanging off the r and the c
requests start off with the same filter list as the connection
the input filter list is not initialized for subrequests
internal redirects start off with the same filter list as the
connection
2) AddInputFilter directive (blatant rip-off of Ryan's AddOutputFilter
directive); as with AddOutputFilter, the network is implicitly to the
right of the specified filter list; this may not be the most
intuitive way to specify the filters; not sure yet
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86403 13f79535-47bb-0310-9956-ffa450edef68
charset of response bodies.
ap_checkconv() is removed, except for in os/bs2000 and os/tpf.
(Anything there is questionable for 2.0 anyway.)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86400 13f79535-47bb-0310-9956-ffa450edef68
lines (netcat) gets a strange looking HTTP_NOT_IMPLEMENTED message.
While I'm in there, start working on ebcdic co-existance with input
filtering.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86397 13f79535-47bb-0310-9956-ffa450edef68
request_rec. This means that a conn_rec must be supplied when calling
ap_add_filter. The reason for this change is that we need to be able to
add the core_filter (whether or SSL or not) before we try to read the
request. This way, if a request fails, we can actually send the error
page back to the client. With this change, we add the core filter to the
conn_rec during the pre-connection phase.
Submitted by: Ryan Bloom, Jeff Trawick, and Greg Ames
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86392 13f79535-47bb-0310-9956-ffa450edef68
instead of the number of bytes sent.
default_handler() ignores the ap_send_fd() return code, but
mod_file_cache doesn't. When mod_file_cache's handler called
ap_send_fd(), the client would get the desired file plus an
error document (500 internal server error), which was delivered
because mod_file_cache's handler returned an error since
ap_send_fd() returned non-zero.
Also in this commit is a hack to be able to compile when APACHE_XLATE
is defined.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86380 13f79535-47bb-0310-9956-ffa450edef68
This implementation is limited to coalescing a single string of small (< MIN_BUCKET_SIZE)
buckets into one large bucket. If a brigade contains a string of small buckets followed by a
large bucket followed by another string of small buckets, only the first string will be coalesced.
This implementation works very well with the output generated by mod_autoindex though.
The number of iovecs handled by http_core is reduced to three from over a thousand for my
test case.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86355 13f79535-47bb-0310-9956-ffa450edef68
ap_send_error_response. The new function simply returns the error response
string corresponding to given HTTP error core. This makes it easier to
change the mechanism for sending these strings, because we no longer have
r[v]puts calls spread throughout the error string generation code.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86341 13f79535-47bb-0310-9956-ffa450edef68
safe to add the core_filter during the post_read_request, and it means
that we only have to add the filter once in the code. This should make
it easier to add an SSL module in the future.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86307 13f79535-47bb-0310-9956-ffa450edef68
HTTP_BAD_REQUEST) don't send any error message content to the browser.
The core_filter wasn't present this early in request parsing, so the output
went into the bit bucket via r[v]puts->ap_pass_brigade.
The chunking filter takes care of itself nicely, because it is added in
ap_send_http_header if it's needed.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86253 13f79535-47bb-0310-9956-ffa450edef68
that have been previously registered with the server. Currently the
directive is only valid inside the config file, but once the Options
directive is tweaked a bit, I would feel more comfortable exposing this
directive to htaccess files.
As a part of making adding this filter, I removed the ctx pointer from the
ap_add_filter prototype. The problem is that the core is the thing that
is actually inserting the filter into the filter stack, but the core doesn't
know how to allocate memory for each filter. The solution is to have the
filters themselves be responsible for allocating the ctx memory whenever
it is required.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86220 13f79535-47bb-0310-9956-ffa450edef68
bound to hard-coded names and a bitmask. We still use the
bitmask for known methods, but we also have an array for
extension method named. Wherever we used the M_* constants
we need to use a routine that knows about the new structure instead.
This is far from complete, but AFAIK this interim work doesn't
break anything -- especially the compile. The rest of the
work will be added in segments; this is just a checkpoint.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86210 13f79535-47bb-0310-9956-ffa450edef68
done by adding a flag to the request_rec. When ap_pass_bucket sees an
EOS bucket, the flag is set. If the flag is still unset when
ap_finalize_request is called, then ap_finalize_request sends an EOS. This
fixes the problem with chunking and CGI.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86202 13f79535-47bb-0310-9956-ffa450edef68
new AP_RING macros. Most of this commit is fairly pedestrian as you
would expect, but I had to redo the chunking filter because of the
amount of pointer juggling it did. I have done some minimal testing
of this patch and it seems to work.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86178 13f79535-47bb-0310-9956-ffa450edef68
we use a modified LIFO. It is modified, because if we add a filter while
in the middle of another filter, the added filter gets put in after the
current filter. This requires that the server is smart about which filters
are added when. This should be handled by the HTTP protocol, but we will
want to keep and eye on things for a little while.
This change is necessary, because currently when we add a filter it goes
after the last filter of the same type. This is broken whenever we want
to add a filter that has a dependancy. Think about the core and chunking
filters. They are of the same type, and core is always added first. When
we go to insert chunking, it gets added, but it is never called.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86161 13f79535-47bb-0310-9956-ffa450edef68
filtering beginning to work. There is a hack that has been repeated
through this patch, we morph a pipe into a socket, and put the socket
into the BUFF. Everytime we do that, we are working with a pipe from
a CGI, and we should be creating a pipe bucket and passing that bucket
back. Because we don't actually have pipe buckets yet, we are using this
hack. When we get pipe buckets, this will be fixed.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86136 13f79535-47bb-0310-9956-ffa450edef68
on buff's translation by default, but mod_charset_lite (when configured
to do so) turned on its own filter-based translation, resulting in
gibberish.
To be determined... whether or not mod_charset_lite should enable
translation of text objects by default (a la 1.3)... probably... for
now you have to tell mod_charset_lite to translate.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86135 13f79535-47bb-0310-9956-ffa450edef68
buckets, and alter the HEAP and MMAP buckets to use it. Change
the way buckets are initialised to support changing the type of
buckets in place, and use it when setting aside TRANSIENT buckets.
Change the implementation of TRANSIENT buckets so that it can be
mostly shared with IMMORTAL buckets, which are now implemented.
Reviewed by: rbb
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86115 13f79535-47bb-0310-9956-ffa450edef68
bucket brigades are sent to this filter, it inserts the chunking header
at the front of the brigade. When the filter sees an EOS bucket, it
adds the 0 chunking trailer.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86090 13f79535-47bb-0310-9956-ffa450edef68
