"-999999" where that is past the end of the file, we should return
a PARTIAL CONTENT status code, and return the whole file as one big
byterange. This matches the 1.3 handling now. [Ryan Bloom]
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87885 13f79535-47bb-0310-9956-ffa450edef68
handlers will send their data down the filter stack, but 1.3 handlers will
just return, giving us a Content-Length of 0. Since we can't send a C-L
of 0 just because it is a HEAD request, we search the headers_out table
for a 0 C-L if it is a HEAD request. The problem is that some filters
will not allow (includes_filter) a C-L to be computed, so we end up without
a C-L header in headers_out. Thus, when we do a strcmp against the header
value and "0", we seg fault, because the header value is NULL.
To fix this, we grab the element from the header table, and make sure it
isn't NULL before doing the strcmp.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87870 13f79535-47bb-0310-9956-ffa450edef68
instead of using ap_bucket_read. It also lets ap_die handle the fact that
the filter returned the error.
Submitted by: Greg Stein
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87867 13f79535-47bb-0310-9956-ffa450edef68
by sending a brigade where the first bucket is an error_bucket.
This bucket is a simple bucket that stores an HTTP error and
a string. Currently the string is not used, but it may be needed
to output an error log. The http_header_filter will find this
bucket, and output the error text, and then return
AP_FILTER_ERROR, which informs the server that the error web page
has already been sent.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87863 13f79535-47bb-0310-9956-ffa450edef68
bug where we were using the byterange filter to filter an error, which
caused us to close the connection before we had sent any data. Currently,
we only keep the three most important filters, but we may need to add more
in the future. I am mostly thinking of the charset translation filter.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87854 13f79535-47bb-0310-9956-ffa450edef68
it also has to happen after ap_basic_http_header. Otherwise, we don't
set r->connection->keepalive correctly, and it can be -1 for requests that
don't support keepalive. This moves ap_basic_http_header to above the
call to set_keepalive (after reversing the previous patch), which should
be perfectly safe, while still fixing the original bug.
Submitted by: Greg Stein
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87824 13f79535-47bb-0310-9956-ffa450edef68
function decl's and CORE_PRIVATE header info should all move into this
header.
Start with moving the filter function declarations.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87808 13f79535-47bb-0310-9956-ffa450edef68
[the context of] a new filter ("OLD_WRITE").
Further information/discussion of this patch is available on new-httpd
between Jan 16 and Jan 23, 2001.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87804 13f79535-47bb-0310-9956-ffa450edef68
copied natively. This will only ever happen if a bucket can be split
but not copied, because we read the bucket in apr_brigade_partition if
we can't split it. Regardless, this is much safer. This should also fix
all of the problems with the byterange filter.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87793 13f79535-47bb-0310-9956-ffa450edef68
return -3 for every HEAD request, which in turn made us call ap_die. Of
course, if we didn't have a 200 status (say we had a 206), then we would
seg fault, because we would end up sending down a second EOS bucket, which
would in turn make us call the byterange filter again, but at this point,
we hadn't cleaned up the byterange ctx structure, because it was never
supposed to be called again.
This was biting us on apache.org, where we had a HEAD request for
bytes=100- for a file. This was a major seg fault. We are better off
just returning OK is much safer.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87788 13f79535-47bb-0310-9956-ffa450edef68
have MMAP, by just checking with APR, instead of using an Apache
definition which doesn't really control anything anymore.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87563 13f79535-47bb-0310-9956-ffa450edef68
problem is that some browsers send an extra line at the end of a POST
request. We use the PEEK method to determine if there is any data left
on the socket, if there is then we delay sending the response until we
have enough data to make it worthwhile. If the browser sends an extra
blank line, we don't want to delay the response at all. The only time
we use the PEEK method is to check for a second request, so this is safe
to do.
This also solves Joe Orton's problem of specifying a Content- Length
of 1 for a blank line, and having the server wait to send back a response.
The problem is that Linux (all Unix really) sends two characters \r\n for
a blank line, so specifying a C-L of 1 means that the server still sees
a \n when it PEEKs that the socket data. That \n can be safely ignored
however.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87540 13f79535-47bb-0310-9956-ffa450edef68
that does not add a content-length. For example, mod_autoindex doesn't
set a content-length, but the byterange filter requires one. We fix this
by computing the content-length in the byterange filter.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87389 13f79535-47bb-0310-9956-ffa450edef68
blocking and non-blocking reads. This allows us to use the mode parameter
passed to a filter to read from the bucket correctly.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87256 13f79535-47bb-0310-9956-ffa450edef68
files need to specifically include stdio.h, or a particular apr_*.h
header.
*) Adjust callers of apr_create_process() to deal with the extra "const"
*) Add "const" to args of ap_os_create_privileged_process()
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87080 13f79535-47bb-0310-9956-ffa450edef68
if/when we compute the content-length. There are just a few cases now:
1) We already have all the data
2) We don't have all the data and:
2a) This is a 1.1 request but we can't chunk
2b) The is a keep-alive request
In the future, we probably want to modify this to not
be a keep-alive request.
This filter always buffers 9K of data. The reason is simple, the core will
buffer 9K at a time anyway, and there is a chance that we may get the end
of the request before we hit 9K. This increases our chances of being able
to send a c-l.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87055 13f79535-47bb-0310-9956-ffa450edef68
ap_send_error_response to the http_header filter. The reason for the move,
is that the header filter takes care of all header processing now. Without
this change, we were sending garbage data to the client whenever we sent
304 responses.
Submitted by: Brian Havard and Ryan Bloom
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87003 13f79535-47bb-0310-9956-ffa450edef68
ugly, but it does proxy pages. This even fixes the content-type bug
that I introduced yesterday sometime. As soon as BUFF is removed from
the FTP proxy, the buff.c and buff.h files need to go away.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86988 13f79535-47bb-0310-9956-ffa450edef68
the content-length is 0. The problem is that the C-L on a HEAD response
has to be the correct C-L, but if a handler returns saying the handled
the request without sending data, the core sends an EOS down the filter
stack, and we compute a 0 C-L.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86976 13f79535-47bb-0310-9956-ffa450edef68
chance to compute the proper content-length before we try to send a set
of headers. If a handler wants to ignore the HEAD method, then it can
either just return from the handler function or pass an EOS bucket down
the filter stack. Either method will still get the headers sent to the
client.
This change allows handlers to actually run the request like it is a GET
request. The core itself will then ensure that no body is sent. This
allows us to get more information about the request before sending out the
headers for the HEAD request.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86954 13f79535-47bb-0310-9956-ffa450edef68
header file. The only time that the C-L should be zero is if there is
no body. Zero is a valid content-length, but the only time that we ever
really send it is on a HEAD request right now, and that is incorrect.
The HEAD response should have the actual content's length.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86953 13f79535-47bb-0310-9956-ffa450edef68
mod_autoindex funky chunking behaviour until the ap_r* routines are reimplemented, at which
time this filter should probably go away.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86943 13f79535-47bb-0310-9956-ffa450edef68
