On 29 Mar 2002 [EMAIL PROTECTED] wrote:
jwoolley02/03/29 00:17:26
Modified:. damn near everything
Log:
BUCKET FREELISTS
Add an allocator-passing mechanism throughout the bucket brigades API.
Yep, that's it... the beast is finally in. I've tested to the best of my
This is *not* equivalent code. In the deleted line the increment happens
*after* the check. In the replacement line of code the increment happens
during the check. This patch is wrong and should be backed out.
Paul J. Reder
[EMAIL PROTECTED] wrote:
bnicholes02/03/28 16:39:56
Nevermind. Should have read the rest of my mail before commenting. I see
that it has already been fixed. Sorry for the noise.
Paul J. Reder wrote:
This is *not* equivalent code. In the deleted line the increment happens
*after* the check. In the replacement line of code the increment happens
[EMAIL PROTECTED] wrote:
jim 02/03/29 06:33:51
Modified:.CHANGES
include scoreboard.h
os/tpf os.c
server scoreboard.c
server/mpm/netware mpm_netware.c
server/mpm/prefork prefork.c
not sure if this is related to the bucket list change or mod_includes
changes or what, but i just checked in a test adapted from modperl that
dumps core. stacktrace below from t/TEST t/modules/include2.t
#0 0x0815a897 in ?? () at eval.c:41
41 eval.c: No such file or directory.
another problem after fixing the httpd-test c-modules to compile:
t/apache/passbrigade eats all cpu. have not looked into it.
Line 3186 in mod_include is hit when it has run through the whole brigade and
found no tags. It is just forwarding the brigade. This will be the normal
case for files that get parsed unnecessarily. This seems to work for me.
No brigades are harmed in this process. I suspect that there is another
On Fri, 29 Mar 2002, Doug MacEachern wrote:
another problem after fixing the httpd-test c-modules to compile:
t/apache/passbrigade eats all cpu. have not looked into it.
nevermind. i didn't notice the modules had been updated and my cvs commit
up-to-date check failed. this test is working
On Fri, 29 Mar 2002, Doug MacEachern wrote:
not sure if this is related to the bucket list change or mod_includes
changes or what, but i just checked in a test adapted from modperl that
dumps core. stacktrace below from t/TEST t/modules/include2.t
fyi: t/php/virtual produces the same
On Fri, 29 Mar 2002, Doug MacEachern wrote:
fyi: t/php/virtual produces the same stacktrace
I'll look into this this afternoon. Has PHP really been updated for the
new buckets API already??
--Cliff
--
Cliff Woolley
[EMAIL
On Fri, 29 Mar 2002, Cliff Woolley wrote:
On Fri, 29 Mar 2002, Doug MacEachern wrote:
fyi: t/php/virtual produces the same stacktrace
I'll look into this this afternoon.
great. probably easier to work with t/modules/include2.t, stacktrace
looks like they suffer the same problem.
This patch updates the readme and install files for TPF.
Minor updates to the latest version of the TPF operating system are now
reflected in the documents.
Also, changes to the documents were made so that they now pass W3C
validation for xhtml 1.0 transitional.
David McCreedy
Title: The Apache
On Fri, 29 Mar 2002, David McCreedy wrote:
This patch updates the readme and install files for TPF.
Minor updates to the latest version of the TPF operating system are now
reflected in the documents.
Also, changes to the documents were made so that they now pass W3C
validation for xhtml
The problem I'm encountering is that ab(1) generates Host: header
pointing to proxy server instead of real destination host.
Due to this behavior, proxy server (not mod_proxy, BTW) is failing
to send a valid HTTP request to destintion webserver using name-based
virtualhost, as it simply
Actually:
The problem I'm encountering is that ab(1) generates Host: header
pointing to proxy server instead of real destination host.
Due to this behavior, proxy server (not mod_proxy, BTW) is failing
to send a valid HTTP request to destintion webserver using name-based
virtualhost, as it
just looked a bit more, the problem is related to heap buckets and the
free functions. something is broken for sure. i could probably bandaid,
but cliff if you take a look, i'm assuming the right fix would be obvious
to you.
#1 0x4001cf76 in heap_destroy (data=0x824f758)
at
I think I am running into the same problem. What I am seeing is that
there is an apr_bucket_heap node on the list that has never been
completely initialized. When memory is allocated on our platform, the
debug code is filling the memory with a specific string. I can tell
that the
On Fri, 29 Mar 2002, Brian Pane wrote:
Does the rest of *h look valid? (That could help us differentiate memory
corruption from some code path that just forgot to set h-free_func.)
(gdb) p *h
$1 = {refcount = {refcount = 0},
base = 0x824f568 mod_include test(\026/\021, alloc_len = 16,
On Fri, 29 Mar 2002, Brad Nicholes wrote:
filled memory. This obviously causes us to fault. I haven't yet been
able to determine where an uninitialized node is being inserted into the
list. All I know is that the base contains a non-NULL terminated
string, alloc_len contains the length of
For HTTP 1.1 you should use the Host: urlhost[:urlport] form. AFAICS
these are the simplest possible proxy requests:
HTTP 1.0:
GET http://www.ibm.com/ HTTP/1.0
crcr
HTTP 1.1:
GET http://www.ibm.com/ HTTP/1.1
Host: www.ibm.com
crcr
Chuck
On Friday, March 29, 2002, at 02:41 PM, [EMAIL
Some advice needed on how to use the Host header when using a proxy and
confirming its limitations with respect to Host: based proxies.
- Consider a proxy proxy.com on port PA
- Consider an origin server or gateway on server.com on port PB
- Consider a URL:
Yes - our mails crossed - quite some change between earlier drafts and the
final RFC2616 which has little guidance for proxies.
Dw.
--
Dirk-Willem van Gulik
On Fri, 29 Mar 2002, Chuck Murcko wrote:
For HTTP 1.1 you should use the Host: urlhost[:urlport] form. AFAICS
these are the simplest
On Fri, 29 Mar 2002, Cliff Woolley wrote:
filled memory. This obviously causes us to fault. I haven't yet been
able to determine where an uninitialized node is being inserted into the
list. All I know is that the base contains a non-NULL terminated
string, alloc_len contains the
On Fri, 29 Mar 2002, Cliff Woolley wrote:
Okay, fixed.
excellent, thanks.
PS: I now pass all httpd-test tests except these:
http.t fails for me too, has for a while.
proxy.t passes for me, but this is new stuff. anything interesting in the
error_log?
On Fri, 29 Mar 2002, Doug MacEachern wrote:
PS: I now pass all httpd-test tests except these:
http.t fails for me too, has for a while.
proxy.t passes for me, but this is new stuff. anything interesting in the
error_log?
Yes. The SSLProxyEngine on directive is missing from the config
On Fri, 29 Mar 2002, Cliff Woolley wrote:
Yes. The SSLProxyEngine on directive is missing from the config file. I
added it manually and it works. I expect something like this would do the
trick:
oh duh, i had made the change but didn't commit. glad to hear it works.
This patch adds a configuration directive ProxyRequireValidHTTPStatus.
When enabled, mod_proxy will require a valid HTTP status line from the
destination server and throw a 502 Bad Gateway error if it does not
get it. Basicaly, this disallows backasswards reponses.
Why would one want to do
While prototyping an apr_allocator_t based implementation for the
bucket allocator, I suddenly realized that there may be a much simpler
way to solve the problem.
The attached implementation handles allocation requests differently
based on their size:
* Anything = 128 bytes is allocated from
28 matches
Mail list logo
