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
content-length has already been set. If we don't, then we won't know if
the content-length has changed because some other filter changed the
length of the actual data. We also ALWAYS want to calculate the content
length if we get the whole brigade in the first call to this function.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86879 13f79535-47bb-0310-9956-ffa450edef68
if we decided to do so initially *and* we've seen all the data.
Prior to this change, for a http/1.1 request to mod_autoindex, the
unconditional call to ap_set_content_length() gave us the wrong
value (only taking into account the first brigade) and disabled
chunking.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86874 13f79535-47bb-0310-9956-ffa450edef68
there is still some bogosity in there (huge buffer allocs!), and some
optimizations to be made, but this appears to fix byterange handling.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86865 13f79535-47bb-0310-9956-ffa450edef68
Acrobat plug-in doesn't like it for some reason. This does work better
than what we currently have, because at least it returns all of the
requested data. This basically removes all BUFFs from the byte-range
code and removes all of the byte-range code from the default-handler.
Byte-ranges are now handled by a filter, which makes sense, and it allows
us to handle byte-ranges for all requests, not just files.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86864 13f79535-47bb-0310-9956-ffa450edef68
