On 15 Jul 2014, at 15:38, Rüdiger Plüm wrote:
> -Original Message-
>> From: Eric Covener [mailto:cove...@gmail.com]
>> Sent: Dienstag, 15. Juli 2014 15:25
>> To: Apache HTTP Server Development List
>> Subject: Re: stop copying footers to r->headers_in?
le)
>
>
> Rick Houser
Rick Houser
Web Administration
(517)367-3516
> -Original Message-
> From: Plüm, Rüdiger, Vodafone Group
> [mailto:ruediger.pl...@vodafone.com]
> Sent: Tuesday, July 15, 2014 10:56 AM
> To: dev@httpd.apache.org
> Subject: RE: stop co
On Tue, Jul 15, 2014 at 11:07 AM, Plüm, Rüdiger, Vodafone Group
wrote:
> This should work. But don't you need to register then ^Ti instead of Ti?
yeah, it needs to be registered and used in httpd.conf w/ the ^
--
Eric Covener
cove...@gmail.com
> -Original Message-
> From: Eric Covener [mailto:cove...@gmail.com]
> Sent: Dienstag, 15. Juli 2014 17:02
> To: Apache HTTP Server Development List
> Subject: Re: stop copying footers to r->headers_in?
>
> On Tue, Jul 15, 2014 at 10:56 AM, Plüm, Rüdiger,
On Tue, Jul 15, 2014 at 10:56 AM, Plüm, Rüdiger, Vodafone Group
wrote:
>
>
>> -Original Message-
>> From: Eric Covener [mailto:cove...@gmail.com]
>> Sent: Dienstag, 15. Juli 2014 16:52
>> To: Apache HTTP Server Development List
>> Subject: Re: s
> -Original Message-
> From: Eric Covener [mailto:cove...@gmail.com]
> Sent: Dienstag, 15. Juli 2014 16:52
> To: Apache HTTP Server Development List
> Subject: Re: stop copying footers to r->headers_in?
>
> On Tue, Jul 15, 2014 at 10:38 AM, Plüm, Rüdiger, Vodafon
On Tue, Jul 15, 2014 at 10:38 AM, Plüm, Rüdiger, Vodafone Group
wrote:
> Is there a way for people with such a setup to fix this with a different
> config?
> From the top of my head I would say no and that would be a blocker.
Do you think the required '^' prefix in the followup is enough? In
th
On Jul 15, 2014, at 10:38 AM, Plüm, Rüdiger, Vodafone Group
wrote:
>
>
>> -Original Message-
>> From: Eric Covener [mailto:cove...@gmail.com]
>> Sent: Dienstag, 15. Juli 2014 15:25
>> To: Apache HTTP Server Development List
>> Subject: Re: s
> -Original Message-
> From: Eric Covener [mailto:cove...@gmail.com]
> Sent: Dienstag, 15. Juli 2014 15:25
> To: Apache HTTP Server Development List
> Subject: Re: stop copying footers to r->headers_in?
>
> Candidate patch uses %I and %O but they are used by mod
ake(pool, 5);
>
> rp->server = r->server;
>
>
> Regards
>
> Rüdiger
>
>> -Original Message-
>> From: Eric Covener [mailto:cove...@gmail.com]
>> Sent: Dienstag, 15. Juli 2014 16:02
>> To: Apache HTTP Server Development List
>>
= apr_table_make(pool, 5);
rp->notes = apr_table_make(pool, 5);
rp->server = r->server;
Regards
Rüdiger
> -Original Message-
> From: Eric Covener [mailto:cove...@gmail.com]
> Sent: Dienstag, 15. Juli 2014 16:02
> To: Apache HTTP Server Developmen
something odd in proxy path when backend has
#0 0x7f16f51b92e1 in apr_table_clear (t=0x0) at tables/apr_tables.c:467
467 t->a.nelts = 0;
(gdb) where
#0 0x7f16f51b92e1 in apr_table_clear (t=0x0) at tables/apr_tables.c:467
#1 0x00483bfc in read_chunked_trailers (ctx=0x7f16
Candidate patch uses %I and %O but they are used by mod_logio. It is
hard to find two good unused characters.
What do people think about allowing two-character log formats? I
think patch below only breaks someone who had a %XX where XX is a
registered two digit tag and they expect the 1 char + l
Patch for trunk as well
On Wed, Jun 25, 2014 at 1:20 PM, Edward Lu wrote:
> Wanted to follow up on this thread again; here's my latest patch on 2.2.x
> that takes some ideas from Joe's patch. I also merge the trailers into the
> headers after reading them now, instead of directly appending them
Wanted to follow up on this thread again; here's my latest patch on 2.2.x
that takes some ideas from Joe's patch. I also merge the trailers into the
headers after reading them now, instead of directly appending them into the
headers.
I will leave the PROXYREQ_RESPONSE case to someone else, as I st
On Wed, May 7, 2014 at 11:47 AM, Joe Orton wrote:
> I hacked the attached up yesterday, before seeing Yann's mail, untested.
The patch looks good (against 2.4.x), but as I said to Edward, I think
r->status should be restored (at least, "error-notes" probably too)
when r->proxyreq == PROXYREQ_RESP
On Tue, May 06, 2014 at 07:45:42PM -0400, Eric Covener wrote:
> On Tue, May 6, 2014 at 6:44 PM, Yann Ylavic wrote:
> > This patch (still) does not propose to merge splitted trailers into
> > headers (for those broken by the change), but when (and why) would we
> > do that?
>
> For 2.2, I would pe
I did not realize your mail is 8 days old, I just received it -- gmail
is having fun these days :(
Sorry for this misunderstanding and the reply that goes along...
Regards,
Yann.
Added mod_log_config changes; I used "O" and "I" for the format letters.
Not sure if there are letters that might be more preferred.
On Fri, May 9, 2014 at 11:01 AM, Edward Lu wrote:
> Here's a 2.2.x backport of Yann's patch with a directive, MergeTrailers,
> added in to opt-in to the old behav
On Mon, May 12, 2014 at 7:03 PM, Edward Lu wrote:
> Both the things you caught were probably just errors I made in manually
> merging the patch into 2.2.x; here's a revised version, just in case.
Looks good, but you did not address Eric's comment about parsing the
trailers directly into trailers_
On May 6, 2014, at 7:45 PM, Eric Covener wrote:
> On Tue, May 6, 2014 at 6:44 PM, Yann Ylavic wrote:
>> On Tue, May 6, 2014 at 1:41 PM, Eric Covener wrote:
>>> I'd really like to start chucking trailers, but the scale of these
>>> patches really frightens me for 2.4 and 2.2 and accompanying wh
Both the things you caught were probably just errors I made in manually
merging the patch into 2.2.x; here's a revised version, just in case.
Thanks for the review.
I'm not really clear on the error-notes discussion. It makes sense that we
wouldn't care too much if we don't save the ones from read
On Sun, May 11, 2014 at 6:35 PM, Yann Ylavic wrote:
> Restoring the status and notes (set before the body is read) seems
> unconditional to me.
Well, actually I'm not really sure whether we should preserve or
overwritte the "error-notes" here.
In most cases (but PROXYREQ_RESPONSE discussed below
On Fri, May 9, 2014 at 5:01 PM, Edward Lu wrote:
> Here's a 2.2.x backport of Yann's patch with a directive, MergeTrailers,
> added in to opt-in to the old behavior. By default, it doesn't merge the
> trailers. I'm working on adding the capability to mod_log_config to log the
> trailers, but I fig
On Wed, May 7, 2014 at 6:35 AM, Ruediger Pluem wrote:
> Configurable by an option? If yes, what is the default behaviour?
my 2 cents:
Default, collect them in r->trailers_in where not much can be done with them.
With a directive, restore the tricky historical behavior (append them
to r->headers_i
Here's a 2.2.x backport of Yann's patch with a directive, MergeTrailers,
added in to opt-in to the old behavior. By default, it doesn't merge the
trailers. I'm working on adding the capability to mod_log_config to log the
trailers, but I figured I'd post this patch first to get some review.
- Ed
Eric Covener wrote:
> On Tue, May 6, 2014 at 6:44 PM, Yann Ylavic wrote:
>> On Tue, May 6, 2014 at 1:41 PM, Eric Covener wrote:
>>> I'd really like to start chucking trailers, but the scale of these
>>> patches really frightens me for 2.4 and 2.2 and accompanying what will
>>> likely be a secur
On Tue, May 6, 2014 at 6:44 PM, Yann Ylavic wrote:
> On Tue, May 6, 2014 at 1:41 PM, Eric Covener wrote:
>> I'd really like to start chucking trailers, but the scale of these
>> patches really frightens me for 2.4 and 2.2 and accompanying what will
>> likely be a security roll-up.
>
> Understood.
On Tue, May 6, 2014 at 1:41 PM, Eric Covener wrote:
> I'd really like to start chucking trailers, but the scale of these
> patches really frightens me for 2.4 and 2.2 and accompanying what will
> likely be a security roll-up.
Understood.
>
> Is anyone sitting on a more tactical version of the fi
I'd really like to start chucking trailers, but the scale of these
patches really frightens me for 2.4 and 2.2 and accompanying what will
likely be a security roll-up.
Is anyone sitting on a more tactical version of the fix?
On Tue, Apr 1, 2014 at 11:35 PM, Yann Ylavic wrote:
> On Tue, Apr 1, 2014 at 8:36 PM, Eric Covener wrote:
>>
>> Can you say roughly how much it has changed, I was largely through a review
>> of the previous patch.
>>
>
> Actually, aside from funcs/vars/params renaming, the only difference
> is a
On Tue, Apr 1, 2014 at 8:00 PM, Yann Ylavic wrote:
> Here is the corresponding patch.
> +static int parse_mime_headers(request_rec *r,
> + apr_bucket_brigade *bb,
> + apr_read_type_e block,
> + ap_filter_t *f, a
Hi Mike,
On Tue, Apr 1, 2014 at 9:21 PM, Mike Rumph wrote:
> Comment included below.
>
> On 4/1/2014 11:00 AM, Yann Ylavic wrote:
>
>> Index: modules/examples/mod_example_hooks.c
>> ===
>> --- modules/examples/mod_example_hooks.c
On Tue, Apr 1, 2014 at 8:36 PM, Eric Covener wrote:
>
> On Tue, Apr 1, 2014 at 2:00 PM, Yann Ylavic wrote:
>>
>> Here is the corresponding patch.
>
>
> I don't know if it's your mail client or mine (gmail), your patches always
> come through as both an attachment and in the body. Usually for anyt
Hello Yann,
Comment included below.
Thanks,
Mike Rumph
On 4/1/2014 11:00 AM, Yann Ylavic wrote:
Index: modules/examples/mod_example_hooks.c
===
--- modules/examples/mod_example_hooks.c(revision 1583714)
+++ modules/examples/m
On Tue, Apr 1, 2014 at 2:00 PM, Yann Ylavic wrote:
> Here is the corresponding patch.
I don't know if it's your mail client or mine (gmail), your patches always
come through as both an attachment and in the body. Usually for anything
more than a few lines, attachment-only is best.
Can you say
On Tue, Apr 1, 2014 at 8:00 PM, Yann Ylavic wrote:
> +static int parse_mime_headers(request_rec *r,
> + apr_bucket_brigade *bb,
> + apr_read_type_e block,
> + ap_filter_t *f, apr_table_t *t,
> +
Sorry I stopped this along the way...
IIRC, my latest patch (not posted yet) does all the necessary in
ap_rgetline_ex() and ap_get_mime_headers_ex() (ie. parameters for the
input filter to read from and handling of the blocking mode), parses
the trailers in ap_http_filter() where they are read, de
Resurrecting this thread. Yann, anything holding this one back?
On Mon, Oct 28, 2013 at 9:43 AM, Yann Ylavic wrote:
> The declaration of ap_get_mime_headers_from() is falsy in the previous
> patch, you should read instead :
>
>
> +AP_DECLARE(apr_status_t)
> +ap_get_mime_headers_from(request_rec
The declaration of ap_get_mime_headers_from() is falsy in the previous
patch, you should read instead :
+AP_DECLARE(apr_status_t)
+ap_get_mime_headers_from(request_rec *r, apr_bucket_brigade *bb,
+ ap_filter_t *from, apr_read_type_e block,
+ apr_tabl
On Mon, Oct 28, 2013 at 2:23 AM, Eric Covener wrote:
> On Tue, Oct 22, 2013 at 2:18 PM, Yann Ylavic wrote:
> > -AP_DECLARE(void) ap_get_mime_headers_core(request_rec *r,
> > apr_bucket_brigade *bb)
> > +struct ap_mime_headers_ctx_t {
> > +int fields_read;
> > +char *last_field;
> > +
On Tue, Oct 22, 2013 at 2:18 PM, Yann Ylavic wrote:
> -AP_DECLARE(void) ap_get_mime_headers_core(request_rec *r,
> apr_bucket_brigade *bb)
> +struct ap_mime_headers_ctx_t {
> +int fields_read;
> +char *last_field;
> +apr_size_t last_len;
> +apr_size_t alloc_len;
> +unsigned int
On Fri, Oct 25, 2013 at 9:12 AM, Yann Ylavic wrote:
> On Thu, Oct 24, 2013 at 7:42 PM, Eric Covener wrote:
>>
>> On Wed, Oct 23, 2013 at 8:04 AM, Yann Ylavic wrote:
>> >> 1) add r->footers_in and use it in 2.2 and up by default
>> > Do that mean no API/ABI change ?
>>
>> In the sense that it nee
On Thu, Oct 24, 2013 at 7:42 PM, Eric Covener wrote:
> On Wed, Oct 23, 2013 at 8:04 AM, Yann Ylavic wrote:
> >> 1) add r->footers_in and use it in 2.2 and up by default
> > Do that mean no API/ABI change ?
>
> In the sense that it needs to be backportable, yes -- but it will mean
> a behavior ch
On Wed, Oct 23, 2013 at 8:04 AM, Yann Ylavic wrote:
> Should I continue this way? Simply to propose patches?
Sorry for not following up earlier. The patches are very much appreciated.
But bite-sized ones are much easier for others to review. This might
often mean fixing the rough corners of ex
Should I continue this way? Simply to propose patches?
On Sat, Oct 19, 2013 at 4:13 PM, Eric Covener wrote:
> Currently, when the body is consumed by a handler, a side effect is
> reading footers that might be present and copying them to
> r->headers_in.
>
> This presents a series of problems.
>
On Oct 21, 2013, at 11:37 AM, Graham Leggett wrote:
> On 21 Oct 2013, at 5:20 PM, Plüm, Rüdiger, Vodafone Group
> wrote:
>
>>> Bikeshed... r->trailers_in? +1 to all this anyway. I'd be tempted to
>>> (lazily) stop here to see whether any users actually care about
>>> trailers. It looks lik
On 21 Oct 2013, at 5:20 PM, Plüm, Rüdiger, Vodafone Group
wrote:
>> Bikeshed... r->trailers_in? +1 to all this anyway. I'd be tempted to
>> (lazily) stop here to see whether any users actually care about
>> trailers. It looks like a pain to thread this change through both
>> versions of ap_ge
> -Original Message-
> From: Joe Orton
> Sent: Montag, 21. Oktober 2013 17:09
> To: dev@httpd.apache.org
> Subject: Re: stop copying footers to r->headers_in?
>
> On Sat, Oct 19, 2013 at 10:13:21AM -0400, Eric Covener wrote:
> > now:
> >
> >
On Sat, Oct 19, 2013 at 10:13:21AM -0400, Eric Covener wrote:
> now:
>
> 1) add r->footers_in and use it in 2.2 and up by default
> 2) add a directive to copy them up to r->headers_in (for those broken
> by the change)
Bikeshed... r->trailers_in? +1 to all this anyway. I'd be tempted to
(lazil
Sounds like a good plan.
Regards
Rüdiger
Eric Covener wrote:
> Currently, when the body is consumed by a handler, a side effect is
> reading footers that might be present and copying them to
> r->headers_in.
>
> This presents a series of problems.
>
> * things that inspect r->headers_in expect
Currently, when the body is consumed by a handler, a side effect is
reading footers that might be present and copying them to
r->headers_in.
This presents a series of problems.
* things that inspect r->headers_in expect it to be fluffed up much
earlier than midway through the handler phase
* if
52 matches
Mail list logo
