Windows 95/98 with binaries compiled on Windows NT. The solution is not specific
toWindows though. Catch up on some CHANGES logging.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86476 13f79535-47bb-0310-9956-ffa450edef68
until we have found a LF, then we send the data up to the previous filter.
I have test on Linux with both Linux's telnet and Win 98 telnet. Win98
uses a char-at-a-time, so this should solve the problem.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86457 13f79535-47bb-0310-9956-ffa450edef68
without sendfile. This also makes the apr_hdtr_t type available on
all platforms, regardless of whether apr_sendfile is defined or not.
Submitted by: Brian Havard and Ryan Bloom
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86437 13f79535-47bb-0310-9956-ffa450edef68
structure. This changes the core_output_filter to use a brigade inside
the conn_rec. Think of this as analagous to the BUFF in the conn_rec.
The idea is that if we have pipelined requests, and it isn't worth it to
send the last bit of data from the first request, we want to save that
extra bit of data to the conn_rec, so that the next request sends it
automatically.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86433 13f79535-47bb-0310-9956-ffa450edef68
The reason is really, really simple. If we ever choose to mix clib and
dos error codes, they criss-cross and don't line up, but they share the
same number space. As I wrote the new APR_IS_ERROR macros, I realized
we were about to shoot ourselves in the foot.
These changes nearly entirely affect Win32 only. The next big patch will
affect all of the rv == APR_ENOENT type problems throughout the system.
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86416 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
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
writev_it_all() in case we have another brigade to process.
Otherwise, nbytes is bogus for the second brigade and
writev_it_all() doesn't know when to quit (it loops).
In writev_it_all(), when compensating for bytes already sent
don't go beyond the number of iovs we were passed on input.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86391 13f79535-47bb-0310-9956-ffa450edef68
brigades across multiple calls until MAX_IOVEC_TO_WRITE or
MIN_SIZE_TO_WRITE thresholds are hit. This implementation does not attempt
to coalesce bytes. Moving a bit further down the filter learning curve...
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86389 13f79535-47bb-0310-9956-ffa450edef68
1) don't compute md5 if we have a content filter; it is almost always wrong
2) add note about adding md5 filter in the future; this can be done
3) delete some APACHE_XLATE/CHARSET_EBCDIC baggage associated with md5
digest support; part of this deleted baggage is a segfault on
subrequests referencing r->rrx (which is not allocated for subrequests)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86385 13f79535-47bb-0310-9956-ffa450edef68
FIN/EOF or error. This meshes with what getline() looks for. It isn't
perfect, but it avoids some nasty loops consuming all available storage
on http/1.1 connections. In keepalive state, we call getline to read the
next request... getline() calls core_input_filter() (indirectly)...
core_input_filter() calls apr_recv() which returns APR_SUCCESS/0 bytes
to signal FIN/EOF. But core_input_filter() returned a bucket with length
zero to getline(), so getline() called core_input_filter() again.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86379 13f79535-47bb-0310-9956-ffa450edef68
in ap_new_connection, but that is bogus, because then other modules can't
put their own filter in. Now, we do this in a new pre-connection hook
function. Later, we will want to add some checking to make sure that this
is really an HTTP request that we are adding the filter for.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86364 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
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
is add part of the infrastructure. Namely:
1) filter list in the conn_rec, which is where the input filter list
must live
2) Split the register_filter into multiple functions, one to register
input filters the other to register output filters.
3) Modify existing modules so they still work.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86251 13f79535-47bb-0310-9956-ffa450edef68
(in various places).
In ab, change the declaration of argv so that it can be passed into
apr_initopt() without warning.
Submitted by: Victor J. Orlikowski <v.j.orlikowski@gte.net>
Reviewed and modified slightly by: Jeff Trawick
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86229 13f79535-47bb-0310-9956-ffa450edef68
and fix the comment explaining how to reduce the incidence of tiny chunks.
Submitted by: Jeff Trawick
Reviewed by: Tony Finch
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86222 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
entry, it saw there were zero bytes and simply returned. the client
would never receive "end of response" and timeout (or the server would
timeout the client).
*) added comments about what is going on
*) place chunk start/end markers around just the content, if that content
is non-zero in length
*) insert all the right "end of response" stuff before the EOS bucket
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86193 13f79535-47bb-0310-9956-ffa450edef68
empty. Avoiding referring to the element type in the macros resulted
in some double dereferences that did the wrong thing.
Reported by: Jeff Trawick
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86184 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
As soon as we hit such a bucket, we'll read from it then pass everything
we have so far on to the next filter. At that point we'll start over.
Also, increase the size of the chunk header buffer to handle larger
lengths.
Note: There is still an extra final chunk header (0) when mod_cgi is used
because EOS is coming down twice.
This is likely to have some bugs here and there. Even worse, it is butt
ugly and in need of simplification.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86155 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
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
1) don't put the trailing 0\r\n\r\n in lenstr; that buffer is
already in use (pointed to by another transient bucket); using
lenstr again overlays that other chunk header
2) insert the bucket with the trailing "0\r\n\r\n" *before* the eos bucket
Submitted by: Jeff Trawick <trawickj@bellsouth.net>
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86095 13f79535-47bb-0310-9956-ffa450edef68
