Uhmmm, this isn't an MMN bump :) If you were adding this new
structure *type* as a member of another structure (say as the last
member of the conn_rec) and the structure grew (in such a way that
folks could be blindly oblivious to the fact that conn_rec just got a
bit bigger), that's an MMN bump.
On Tue, 3 Feb 2004, William A. Rowe, Jr. wrote:
> Uhmmm, this isn't an MMN bump :) If you were adding this new
> structure *type* as a member of another structure (say as the last
> member of the conn_rec) and the structure grew (in such a way that
> folks could be blindly oblivious to the fact t
* Cliff Woolley <[EMAIL PROTECTED]> wrote:
> On Tue, 3 Feb 2004, William A. Rowe, Jr. wrote:
>
> > Uhmmm, this isn't an MMN bump :) If you were adding this new
> > structure *type* as a member of another structure (say as the last
> > member of the conn_rec) and the structure grew (in such a way
[EMAIL PROTECTED] wrote:
> geoff 2004/04/08 17:56:26
>
> Modified:.CHANGES
>server core.c
> Log:
> Enable special ErrorDocument value 'default' which restores the
> canned server response for the scope of the directive.
if this stays in 2.1 it will ne
On Thu, 8 Apr 2004, Geoffrey Young wrote:
> [EMAIL PROTECTED] wrote:
> > geoff 2004/04/08 17:56:26
> >
> > Modified:.CHANGES
> >server core.c
> > Log:
> > Enable special ErrorDocument value 'default' which restores the
> > canned server response for the
> Just edit the .xml. (There is a big ugly note at the top of the .html.en
> telling you not to touch it.) Then you can build the .html.en using
> the instructions here:
> http://httpd.apache.org/docs-project/docsformat.html
> Or if you don't want to bother, just do the .xml and someone else wi
On Sat, 10 Apr 2004 [EMAIL PROTECTED] wrote:
> nd 2004/04/10 14:44:43
>
> Modified:.CHANGES
>server core.c
> Log:
> accept URLs as ServerAdmin contact. If it's not recognized as an URL, assume
> an email address and prepend it with mailto: in server
* Joshua Slive <[EMAIL PROTECTED]> wrote:
> > Modified:.CHANGES
> >server core.c
> > Log:
> > accept URLs as ServerAdmin contact. If it's not recognized as an URL,
> > assume an email address and prepend it with mailto: in server outputs.
>
> Careful with thi
[EMAIL PROTECTED] wrote:
> nd 2004/04/10 11:40:53
>
> Modified:server core.c
> Log:
> "ErrorDocument default" changes broke inheritance. consider:
>
>
> ErrorDocument 404 blah
>
>
> ErrorDocument 500 boo
> # 404 is now fallen back to default
>
>
> T
[EMAIL PROTECTED] wrote:
jorton 2004/05/17 08:24:31
Modified:server core.c
Log:
* server/core.c (core_output_filter): Don't explicitly delete the EOC
bucket, and don't buffer the brigade if it ends in an EOC.
Won't this change result in a memory leak?
Bill
On Mon, May 17, 2004 at 01:06:04PM -0400, Bill Stoddard wrote:
> [EMAIL PROTECTED] wrote:
> >jorton 2004/05/17 08:24:31
> >
> > Modified:server core.c
> > Log:
> > * server/core.c (core_output_filter): Don't explicitly delete the EOC
> > bucket, and don't buffer the brigade if it end
[EMAIL PROTECTED] wrote:
gregames2002/12/09 14:19:26
Modified:.CHANGES
server core.c
Log:
core_output_filter: re-instate the deferred_write pool patch so we don't
leak fd's until the end of a keepalive connection.
Thanks to:
Jeff Trawick for the o
On Wed, 8 Jan 2003, Greg Ames wrote:
> Can I get some +1's for moving this into stable (or -1's and reasons not
> to do so)?
>
> - Its one month birthday is tomorrow,
> - it is certainly in mainline code, and
> - AFAIK it hasn't caused any problems since the apr_mmap ownership redesign.
+1 from h
> From: Cliff Woolley [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 08, 2003 5:29 PM
> On Wed, 8 Jan 2003, Greg Ames wrote:
>
> > Can I get some +1's for moving this into stable (or -1's and reasons not
> > to do so)?
> >
> > - Its one month birthday is tomorrow,
> > - it is certainly in
Martin,
where the path is altogether invalid, ap_server_root_relative() may return
NULL (there was no better method for reporting an error.) One can assume
the only possible error if NULL was APR_EBADPATH. Of course, within
ap_server_root_relative() we already invoke apr_filepath_merge() so th
At 11:00 AM 9/25/2003, [EMAIL PROTECTED] wrote:
>trawick 2003/09/25 09:00:57
>
> Modified:.CHANGES
> server core.c
> Log:
> Log an error when requests for URIs which fail to map to a valid
> filesystem name are rejected with 403.
>
> +ap_log_rerror
William A. Rowe, Jr. wrote:
At 11:00 AM 9/25/2003, [EMAIL PROTECTED] wrote:
trawick 2003/09/25 09:00:57
Modified:.CHANGES
server core.c
Log:
Log an error when requests for URIs which fail to map to a valid
filesystem name are rejected with 403.
+ap_log_
[EMAIL PROTECTED] wrote:
> trawick 2003/12/10 14:40:33
>
> Modified:.CHANGES
>server core.c
> Log:
> Fix and parsing to require a closing '>'
> in the initial container.
>
> PR:25414
> Submitted by: Geoffrey Young ]
>
On 23 Aug 2001 [EMAIL PROTECTED] wrote:
> trawick 01/08/23 16:49:41
>
> Modified:server core.c
> Log:
> fix fubar with recent commit to ap_core_translate()
>
>}
> -r->canonical_filename == r->filename;
> +r->canonical_filename = r->filename;
>
Cliff Woolley <[EMAIL PROTECTED]> writes:
> Crap, and I saw those (briefly), too... I thought they looked strange for
> some reason but didn't focus on it long enough to see the obvious. I
> wonder why the hell didn't this cause a gcc warning?
>From a regression test report:
/home/regress/regr
On 23 Aug 2001, Jeff Trawick wrote:
> > core.c: In function `ap_core_translate':
> > core.c:2921: warning: statement with no effect
> > core.c:2936: warning: statement with no effect
> > mod_include.c: In function `split_and_pass_pretag_buckets':
> > mod_include.c:122: warning: control reaches en
If you thought this patch;
> --- mod_mime.c 2001/08/28 15:31:08 1.60
> +++ mod_mime.c 2001/08/30 04:11:57 1.61
> @@ -116,8 +116,6 @@
>
>apr_array_header_t *remove_mappings; /* A simple list, walked once */
>
> -char *type; /* Type forced with ForceType
>module AP_MODULE_DECLARE_DATA cgi_module;
>
> +/* There has to be a better place to put this - uhm... where exactly? */
> +/**
> + * Reprocess the command and arguments to execute the given CGI script.
> + * @param cmd Pointer to the command to execute (may be overridden)
> + * @pa
On 5 Oct 2001 [EMAIL PROTECTED] wrote:
> ap_brigade_partition does a blocking read.
Correct.
> Ryan, Greg, and others can figure out if ap_brigade_partition should
> be tweaked to handle AP_NONBLOCK_READ natively. I'm of a mixed mind,
> but this addresses the short term need.
No, it s
On Fri, Oct 05, 2001 at 03:10:55PM -0400, Cliff Woolley wrote:
> On 5 Oct 2001 [EMAIL PROTECTED] wrote:
>
> > ap_brigade_partition does a blocking read.
>
> Correct.
>
> > Ryan, Greg, and others can figure out if ap_brigade_partition should
> > be tweaked to handle AP_NONBLOCK_READ native
On Friday 05 October 2001 12:21 pm, Justin Erenkrantz wrote:
> Yup, that's what I was thinking. =)
>
> Now, what about the case that we want to do a blocking read but we
> don't really know how much to read? I think it is analogous to the
> non-blocking case (what this commit does), but it just
On Fri, Oct 05, 2001 at 12:55:59PM -0700, Ryan Bloom wrote:
> On Friday 05 October 2001 12:21 pm, Justin Erenkrantz wrote:
>...
> > So, I'm thinking a new ap_get_brigade mode called
> > AP_BLOCKING_PARTIAL_MODE might do the trick. It tells the core input
> > filter that it is okay to return less
Note that all of this becomes *much* easier if we just switch over to
directly reading the socket.
Cheers,
-g
On Fri, Oct 05, 2001 at 08:54:19AM -, [EMAIL PROTECTED] wrote:
> jerenkrantz01/10/05 01:54:19
>
> Modified:server core.c
> Log:
> Allow the core input filter to hand
On Fri, Oct 19, 2001 at 02:05:48AM -, [EMAIL PROTECTED] wrote:
> wrowe 01/10/18 19:05:48
>
> Modified:server core.c
> Log:
> Guys... please be _careful_ when you pcalloc -> palloc!!!
>
> Resolves GAmes' segfault observations
>
> Revision ChangesPath
> 1.
I brought this up once before. I think it was Aaron that suggested an
"optimization" which changed a pcalloc to a palloc. I noted that doing
things like that are troublesome for long term maintenance.
Bam. Empirical evidence here.
Changing pcalloc to palloc should only be done when we have speci
From: "Greg Stein" <[EMAIL PROTECTED]>
Sent: Friday, October 19, 2001 7:18 AM
> I brought this up once before. I think it was Aaron that suggested an
> "optimization" which changed a pcalloc to a palloc. I noted that doing
> things like that are troublesome for long term maintenance.
>
> Bam. E
> I brought this up once before. I think it was Aaron that suggested an
> "optimization" which changed a pcalloc to a palloc. I noted that doing
> things like that are troublesome for long term maintenance.
>
> Bam. Empirical evidence here.
>
> Changing pcalloc to palloc should only be done when
[EMAIL PROTECTED] wrote:
>
> Guys... please be _careful_ when you pcalloc -> palloc!!!
:
> +else
> +base->response_code_strings = NULL;
> +
And please abide by the style guide:
else {
base->response_code_strings = NULL;
}
--
#kenP-)}
Ken Coar,
On Fri, Oct 19, 2001 at 05:18:03AM -0700, Greg Stein wrote:
> I brought this up once before. I think it was Aaron that suggested an
> "optimization" which changed a pcalloc to a palloc. I noted that doing
> things like that are troublesome for long term maintenance.
I brought it up once, but my p
On Friday 19 October 2001 09:17 am, Aaron Bannert wrote:
> On Fri, Oct 19, 2001 at 05:18:03AM -0700, Greg Stein wrote:
> > I brought this up once before. I think it was Aaron that suggested an
> > "optimization" which changed a pcalloc to a palloc. I noted that doing
> > things like that are troub
Aaron Bannert wrote:
>On Fri, Oct 19, 2001 at 05:18:03AM -0700, Greg Stein wrote:
>
>>I brought this up once before. I think it was Aaron that suggested an
>>"optimization" which changed a pcalloc to a palloc. I noted that doing
>>things like that are troublesome for long term maintenance.
>>
>
>
On Fri, 19 Oct 2001, Aaron Bannert wrote:
> > Changing pcalloc to palloc should only be done when we have specific
> > information that it is *really* helpful.
>
> I agree that in general we probably don't want to go around replacing
> these things everywhere, but in some cases (like inside a tig
my personal opinion is that most uses of pcalloc() are just lazy
programming.
if maintainability is an issue then make a creator function or macro for
your data structures.
the only thing empirical here is that the person doing the pcalloc to
palloc change wasn't thorough enough. it doesn't pro
On Sat, Oct 20, 2001 at 06:29:09PM -, [EMAIL PROTECTED] wrote:
> wrowe 01/10/20 11:29:09
>
> Modified:server core.c
> Log:
> Canonicalize all absolute sections, not simply those that
> fail to end in a '/'. Slash test is afterwords, once we've canonicalized
> any
> On Sat, Oct 20, 2001 at 06:29:09PM -, [EMAIL PROTECTED] wrote:
> > wrowe 01/10/20 11:29:09
> >
> > Modified:server core.c
> > Log:
> > Canonicalize all absolute sections, not simply those that
> > fail to end in a '/'. Slash test is afterwords, once we've canonical
On Mon, Oct 22, 2001 at 04:36:46AM -, [EMAIL PROTECTED] wrote:
> wrowe 01/10/21 21:36:46
>
> Modified:server core.c
> Log:
> Fix two typos in the last patch... compiles/tests clean... Greg, please
> run this against Apache.org until the first core and post the results.
From: "Greg Stein" <[EMAIL PROTECTED]>
Sent: Monday, October 22, 2001 8:53 AM
> On Mon, Oct 22, 2001 at 04:36:46AM -, [EMAIL PROTECTED] wrote:
> > wrowe 01/10/21 21:36:46
> >
> > Modified:server core.c
> > Log:
> > Fix two typos in the last patch... compiles/tests clean.
[EMAIL PROTECTED] wrote:
>
> wrowe 01/10/21 21:36:46
>
> Modified:server core.c
> Log:
> Fix two typos in the last patch... compiles/tests clean... Greg, please
> run this against Apache.org until the first core and post the results.
So far, so good. No more seg faults
From: "Greg Ames" <[EMAIL PROTECTED]>
Sent: Monday, October 22, 2001 4:12 PM
> [EMAIL PROTECTED] wrote:
> >
> > wrowe 01/10/21 21:36:46
> >
> > Modified:server core.c
> > Log:
> > Fix two typos in the last patch... compiles/tests clean... Greg, please
> > run this again
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
Sent: Monday, October 22, 2001 4:31 PM
> From: "Greg Ames" <[EMAIL PROTECTED]>
> Sent: Monday, October 22, 2001 4:12 PM
>
>
> > [EMAIL PROTECTED] wrote:
> > >
> > > wrowe 01/10/21 21:36:46
> > >
> > > Modified:server core.c
> > >
[EMAIL PROTECTED] wrote:
>
> jwoolley01/10/23 02:41:54
> Modified:server core.c
> Log:
> Fix a segfault seen on daedalus earlier this evening.
Thanks!
(02:41...h, he knows buckets well enough to code in his sleep ;-)
Greg
On Tue, 23 Oct 2001, Greg Ames wrote:
> > jwoolley01/10/23 02:41:54
>
> > Modified:server core.c
> > Log:
> > Fix a segfault seen on daedalus earlier this evening.
>
> Thanks!
>
> (02:41...h, he knows buckets well enough to code in his sleep ;-)
02:41 daedalus time =
[EMAIL PROTECTED] writes:
> Index: core.c
> ===
> RCS file: /home/cvs/httpd-2.0/server/core.c,v
> retrieving revision 1.81
> retrieving revision 1.82
> diff -u -r1.81 -r1.82
> --- core.c 2001/10/23 09:41:54 1.81
>
Brian Pane wrote:
> Aaron Bannert wrote:
[...]
>> I agree that in general we probably don't want to go around replacing
>> these things everywhere, but in some cases (like inside a tight loop
>> in a filter that gets called many times during a single request) it may
>> make sense. But that's w
From: <[EMAIL PROTECTED]>
Sent: Wednesday, October 31, 2001 12:21 PM
> aaron 01/10/31 10:21:53
>
> Modified:server core.c
> Log:
> Fix a big memory leak bug related to arbitrarily large header lines.
> The core input filter would happily consume all the data you gave it
>
On Wed, Oct 31, 2001 at 12:37:22PM -0600, William Rowe wrote:
> > aaron 01/10/31 10:21:53
> >
> > Modified:server core.c
> > Log:
> > Fix a big memory leak bug related to arbitrarily large header lines.
> > The core input filter would happily consume all the data you gave it
>
[EMAIL PROTECTED] wrote:
>
> The core input filter would happily consume all the data
> you gave it in a header line, looking for that one LF.
> This patch limits that "getline" functionality to
> HUGE_STRING_LEN (8192 bytes).
Shouldn't that use the value from the LimitRequestFieldSize
directive
> [EMAIL PROTECTED] wrote:
> >
> > The core input filter would happily consume all the data
> > you gave it in a header line, looking for that one LF.
> > This patch limits that "getline" functionality to
> > HUGE_STRING_LEN (8192 bytes).
>
> Shouldn't that use the value from the LimitRequestFi
On Wed, Oct 31, 2001 at 02:16:12PM -0500, Bill Stoddard wrote:
>
> > [EMAIL PROTECTED] wrote:
> > >
> > > The core input filter would happily consume all the data
> > > you gave it in a header line, looking for that one LF.
> > > This patch limits that "getline" functionality to
> > > HUGE_STRIN
Rodent of Unusual Size wrote:
>
> [EMAIL PROTECTED] wrote:
> >
> > The core input filter would happily consume all the data
> > you gave it in a header line, looking for that one LF.
> > This patch limits that "getline" functionality to
> > HUGE_STRING_LEN (8192 bytes).
>
> Shouldn't that use th
Greg Ames wrote:
>
> * The core input filter has no idea if it's working on
> a request line or header line.
Then I consider this perilously close to a showstopper
for GA; the Limit* directives, which were added for a
reason, appear worthless -- an unacceptable regression.
Does even LimitReque
On Wed, Oct 31, 2001 at 02:50:54PM -0500, Rodent of Unusual Size wrote:
> > * The core input filter has no idea if it's working on
> > a request line or header line.
>
> Then I consider this perilously close to a showstopper
> for GA; the Limit* directives, which were added for a
> reason, appe
Rodent of Unusual Size wrote:
>
> Greg Ames wrote:
> >
> > * The core input filter has no idea if it's working on
> > a request line or header line.
>
> Then I consider this perilously close to a showstopper
> for GA; the Limit* directives, which were added for a
> reason, appear worthless --
Aaron Bannert wrote:
>
> On Wed, Oct 31, 2001 at 02:16:12PM -0500, Bill Stoddard wrote:
> >
> > > [EMAIL PROTECTED] wrote:
> > > >
> > > > The core input filter would happily consume all the data
> > > > you gave it in a header line, looking for that one LF.
> > > > This patch limits that "getlin
From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
Sent: Wednesday, October 31, 2001 2:00 PM
> Yes, they are worthless because the core input filter has no way of
> knowing if it is working on a request, header, or body line.
It never needs to know.
> There is simply a call to ap_get_brigade wit
On Wed, Oct 31, 2001 at 02:18:58PM -0600, William Rowe wrote:
> From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
> Sent: Wednesday, October 31, 2001 2:00 PM
>
>
> > Yes, they are worthless because the core input filter has no way of
> > knowing if it is working on a request, header, or body line.
typo clarification...
> I think this comes all the way back to the ideas I was forming on the
> apr-serf list about what types of data a bucket can represent. Having
> boundary conditions implies uniform units of data, but that is now how our
just to be clear, I meant:
...but that is not how our
From: "Aaron Bannert" <[EMAIL PROTECTED]>
Sent: Wednesday, October 31, 2001 2:54 PM
> On Wed, Oct 31, 2001 at 02:18:58PM -0600, William Rowe wrote:
> >
> > The most efficient model is for the consumer to keep calling the chain
> > until it has sufficient bytes for what it is trying to query [be
On Sun, Nov 18, 2001 at 02:57:13AM -, [EMAIL PROTECTED] wrote:
> ianh01/11/17 18:57:13
>
> Modified:include http_core.h
>server core.c
> Log:
> change the signature of ap_custom_response() to use a
> "const char *" instead of a "char *".
Okay in concept
On Wed, 2001-11-21 at 10:25, [EMAIL PROTECTED] wrote:
> rbb 01/11/21 10:25:40
>
> Modified:modules/generators config5.m4
>server core.c
hey Ryan
you forgot to add test_pass_brigade.c
to CVS
> Log:
> Fix a bug in our output filter buffering. If a lot of small
On Wednesday 21 November 2001 12:00 pm, Ian Holsman wrote:
> On Wed, 2001-11-21 at 10:25, [EMAIL PROTECTED] wrote:
> > rbb 01/11/21 10:25:40
> >
> > Modified:modules/generators config5.m4
> >server core.c
>
> hey Ryan
> you forgot to add test_pass_brigade.c
> to CVS
On Monday 26 November 2001 12:49 am, [EMAIL PROTECTED] wrote:
> brianp 01/11/26 00:49:29
>
> Modified:server core.c
> Log:
> Another fix for the core_output_filter() code that concatenates
> small buckets: It's possible for the temporary brigade to
> contain more than one buck
Ryan Bloom wrote:
>On Monday 26 November 2001 12:49 am, [EMAIL PROTECTED] wrote:
>
>>brianp 01/11/26 00:49:29
>>
>> Modified:server core.c
>> Log:
>> Another fix for the core_output_filter() code that concatenates
>> small buckets: It's possible for the temporary brigade to
>> con
On Monday 26 November 2001 07:43 am, Brian Pane wrote:
> Ryan Bloom wrote:
> >On Monday 26 November 2001 12:49 am, [EMAIL PROTECTED] wrote:
> >>brianp 01/11/26 00:49:29
> >>
> >> Modified:server core.c
> >> Log:
> >> Another fix for the core_output_filter() code that concatenates
> >
On 26 Nov 2001 [EMAIL PROTECTED] wrote:
> +for (next = APR_BRIGADE_FIRST(temp_brig);
> + next != APR_BRIGADE_SENTINEL(temp_brig);
> + next = APR_BRIGADE_FIRST(temp_brig)) {
> +
> wrowe 01/12/12 16:43:14
>
> Modified:server core.c
> Log:
> Whatever this was doing, it looks most unholy.
>
> Revision ChangesPath
> 1.114 +10 -6 httpd-2.0/server/core.c
>
> Index: core.c
> =
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
> wrowe 01/12/12 21:49:28
>
> Modified:server core.c
> Log:
> Now all should be well. AcceptPathInfo on will give us a
> document with
> path_info served from the core handler. Any filters can then
> manipulate
On Wed, Jan 02, 2002 at 07:56:25AM -, [EMAIL PROTECTED] wrote:
> jerenkrantz02/01/01 23:56:25
>
> Modified:.CHANGES
>include http_core.h
>modules/http http_protocol.c
>server core.c
Note that HTTP_IN now calls ap_die on an
<[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 02, 2002 2:56 AM
Subject: cvs commit: httpd-2.0/server core.c
> jerenkrantz02/01/01 23:56:25
>
> Modified:.CHANGES
>include http_core.h
>
On Wed, Jan 02, 2002 at 05:15:34PM -0500, Bill Stoddard wrote:
> This patch breaks the proxy. Specifically, anyone who uses
>ap_proxy_make_fake_req(). Get
> a seg fault in ap_get_limit_req_body because r->per_dir_config is NULL. I'll spend
>some
> time on this tomorrow unless someone wants to
From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
Sent: Wednesday, January 02, 2002 4:15 PM
> On Wed, Jan 02, 2002 at 05:15:34PM -0500, Bill Stoddard wrote:
> > This patch breaks the proxy. Specifically, anyone who uses
>ap_proxy_make_fake_req(). Get
> > a seg fault in ap_get_limit_req_body becau
From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Wednesday, January 02, 2002 4:15 PM
> This patch breaks the proxy. Specifically, anyone who uses
>ap_proxy_make_fake_req(). Get
> a seg fault in ap_get_limit_req_body because r->per_dir_config is NULL. I'll spend
>some
> time on this tomorrow
On Wed, Jan 02, 2002 at 04:46:01PM -0600, William A. Rowe, Jr. wrote:
> Broke more than proxy, without a rebuild all. Time for an MMN bump, it seems :)
I was wondering about that. =) What are the rules for a MMN bump?
-- justin
From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
Sent: Wednesday, January 02, 2002 4:56 PM
> On Wed, Jan 02, 2002 at 04:46:01PM -0600, William A. Rowe, Jr. wrote:
> > Broke more than proxy, without a rebuild all. Time for an MMN bump, it seems :)
>
> I was wondering about that. =) What are the
> From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
> Sent: Wednesday, January 02, 2002 4:56 PM
>
>
> > On Wed, Jan 02, 2002 at 04:46:01PM -0600, William A. Rowe, Jr. wrote:
> > > Broke more than proxy, without a rebuild all. Time for an MMN bump, it seems :)
> >
> > I was wondering about that. =)
From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Wednesday, January 02, 2002 8:25 PM
> > BTW --- 1.3.23 question here; The API_EXPORT -> API_EXPORT_NONSTD changes in
> > theory require an MMN bump on Win32. Which really sucks, because I don't want
> > to break everyone else. Anyone given any th
>
> > On Wed, Jan 02, 2002 at 05:15:34PM -0500, Bill Stoddard wrote:
> > > This patch breaks the proxy. Specifically, anyone who uses
ap_proxy_make_fake_req(). Get
> > > a seg fault in ap_get_limit_req_body because r->per_dir_config is NULL. I'll
>spend
some
> > > time on this tomorrow unless
On Thursday 03 January 2002 05:16 am, Bill Stoddard wrote:
> >
> > > On Wed, Jan 02, 2002 at 05:15:34PM -0500, Bill Stoddard wrote:
> > > > This patch breaks the proxy. Specifically, anyone who uses
> ap_proxy_make_fake_req(). Get
> > > > a seg fault in ap_get_limit_req_body because r->per_dir_c
t;
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, January 02, 2002 2:56 AM
> Subject: cvs commit: httpd-2.0/server core.c
>
>
> > jerenkrantz02/01/01 23:56:25
> >
> > Modified:.CHANGES
> >include http_core.h
> >
g is NULL. I'll
>spend some
> > time on this tomorrow unless someone wants to jump on it tonight.
> >
> > Bill
> >
> > - Original Message -
> > From: <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> >
From: "Ryan Bloom" <[EMAIL PROTECTED]>
Sent: Thursday, January 03, 2002 10:14 AM
> On Thursday 03 January 2002 05:16 am, Bill Stoddard wrote:
> > >
> > > > Is it valid for r->per_dir_config to be null? Hmm. I wonder if
> > > > ap_get_limit_req_body should be fixed to handle this case instead
>
> From: "Ryan Bloom" <[EMAIL PROTECTED]>
> Sent: Thursday, January 03, 2002 10:14 AM
>
>
> > On Thursday 03 January 2002 05:16 am, Bill Stoddard wrote:
> > > >
> > > > > Is it valid for r->per_dir_config to be null? Hmm. I wonder if
> > > > > ap_get_limit_req_body should be fixed to handle this
On Thu, Jan 03, 2002 at 02:31:49PM -0500, Bill Stoddard wrote:
> I've spent some time on this and this is one reason I am sort of interested in a
>proxy
> specific input filter. I agree with Ryan that 99.9% would be identical to what is
>already
> in HTTP_IN now.
Then, why have a separate inpu
> On Thu, Jan 03, 2002 at 02:31:49PM -0500, Bill Stoddard wrote:
> > I've spent some time on this and this is one reason I am sort of interested in a
>proxy
> > specific input filter. I agree with Ryan that 99.9% would be identical to what is
already
> > in HTTP_IN now.
>
> Then, why have a sep
On Thursday 03 January 2002 11:31 am, Bill Stoddard wrote:
> > The real question
> > is what is the request actually using within this dummy configuration, and that
> > would require some single stepping I don't have time for this week.
> >
> I've spent some time on this and this is one reason I a
On Sun, Jan 20, 2002 at 11:43:37AM -, [EMAIL PROTECTED] wrote:
> jerenkrantz02/01/20 03:43:37
>
> Modified:server core.c
> Log:
> Make core_input_filter use the new apr_brigade_split_line function.
I went ahead and added some functions that we have previously
discussed addin
[EMAIL PROTECTED] writes:
> stoddard02/01/29 17:57:53
>
> Modified:server core.c
> Log:
> Now how did this slip by. Fixes a segfault. I tested this code, really...
I'm not sure this is the only one.
var decls:
core_net_rec *net = f->ctx;
core_ctx_t *ctx = net->in_ctx;
I suspect something is messed up in your build. f->ctx (and net->c) are both
initialized
in the core_install_transport_filters(conn_rec *c, apr_socket_t *csd) call. It compiles
and serves pages cleanly for me. Can you verify if core_install_transport_filters is
being
run?
Bill
> [EMAIL PROTECT
"Bill Stoddard" <[EMAIL PROTECTED]> writes:
> I suspect something is messed up in your build.
never :) (seriously... I spend most of my day watching "make
extraclean" scroll by... even after a config file change)
All I gotta say is:
#0 core_output_filter (f=0x40615fec, b=0x405ddff4) at cor
"Bill Stoddard" <[EMAIL PROTECTED]> writes:
> I suspect something is messed up in your build. f->ctx (and net->c) are both
>initialized
> in the core_install_transport_filters(conn_rec *c, apr_socket_t *csd) call. It
>compiles
> and serves pages cleanly for me. Can you verify if core_install_tr
return OK;
}
- Original Message -
From: "Jeff Trawick" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 29, 2002 9:54 PM
Subject: Re: cvs commit: httpd-2.0/server core.c
> "Bill Stoddard" <[EMAIL PROTECTED]> writes:
>
> > I suspect so
"Bill Stoddard" <[EMAIL PROTECTED]> writes:
> Compiles but not tested.
it works for me...
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
> "Bill Stoddard" <[EMAIL PROTECTED]> writes:
>
> > Compiles but not tested.
>
> it works for me...
Just tested it on Windows. Bombs w/o the patch. Ok with. Committing.
Bill
On Tue, Feb 05, 2002 at 10:56:44PM -, [EMAIL PROTECTED] wrote:
> trawick 02/02/05 14:56:44
>
> Modified:.CHANGES
>server core.c
> Log:
> In core_input_filter, check for an empty brigade after
> APR_BRIGADE_NORMALIZE(). Otherwise, we can get segfaults
Justin Erenkrantz <[EMAIL PROTECTED]> writes:
> On Tue, Feb 05, 2002 at 10:56:44PM -, [EMAIL PROTECTED] wrote:
> > trawick 02/02/05 14:56:44
> >
> > Modified:.CHANGES
> >server core.c
> > Log:
> > In core_input_filter, check for an empty brigade after
1 - 100 of 218 matches
Mail list logo
