On Fri, Jun 5, 2015 at 1:05 AM, William A Rowe Jr
wrote:
> On Fri, Jun 5, 2015 at 12:42 AM, Christophe JAILLET <
> christophe.jail...@wanadoo.fr> wrote:
>>
>> This has been fixed in trunk in r1619453. ( APLOGNO(02805) )
>
>
> Would you propose the backport? TIA!
>
And... I see you did :) Thank
On Fri, Jun 5, 2015 at 12:42 AM, Christophe JAILLET <
christophe.jail...@wanadoo.fr> wrote:
>
> This has been fixed in trunk in r1619453. ( APLOGNO(02805) )
Would you propose the backport? TIA!
I'm not compiling -Wall... so
/opt/apr15/build-1/libtool --silent --mode=compile gcc -std=gnu99
-I/usr/include/libxml2 -g -O2 -pthread -DLINUX -D_REENTRANT
-D_GNU_SOURCE -I. -I/home/wrowe/dev/httpd-2.4/os/unix
-I/home/wrowe/dev/httpd-2.4/include -I/opt/apr15/include/apr-1
-I/usr/local/ssl
Le 05/06/2015 07:11, Gregg Smith a écrit :
On 6/4/2015 10:01 PM, William A Rowe Jr wrote:
On Thu, Jun 4, 2015 at 10:47 PM, Gregg Smith wrote:
This is new, not quite sure how I didn't see it a few weeks ago as
it's 9
weeks old.
Who forgot to fill in the number?
mod_deflate.c(1283) : warning
On 06/05/2015 07:01 AM, William A Rowe Jr wrote:
On Thu, Jun 4, 2015 at 10:47 PM, Gregg Smith mailto:g...@gknw.net>> wrote:
This is new, not quite sure how I didn't see it a few weeks ago as
it's 9 weeks old.
Who forgot to fill in the number?
mod_deflate.c(1283) : warning C4003
On 6/4/2015 10:01 PM, William A Rowe Jr wrote:
On Thu, Jun 4, 2015 at 10:47 PM, Gregg Smith wrote:
This is new, not quite sure how I didn't see it a few weeks ago as it's 9
weeks old.
Who forgot to fill in the number?
mod_deflate.c(1283) : warning C4003: not enough actual parameters for
macro
On Thu, Jun 4, 2015 at 10:47 PM, Gregg Smith wrote:
>
> This is new, not quite sure how I didn't see it a few weeks ago as it's 9
> weeks old.
> Who forgot to fill in the number?
>
> mod_deflate.c(1283) : warning C4003: not enough actual parameters for
> macro 'APLOGNO'
>
I just rechecked my com
This is new, not quite sure how I didn't see it a few weeks ago as it's
9 weeks old.
Who forgot to fill in the number?
mod_deflate.c(1283) : warning C4003: not enough actual parameters for
macro 'APLOGNO'
On 05/06/2015 02:33, Jim Jagielski wrote:
> The pre-release test tarballs for Apache httpd 2.4.13 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/ [1]
>
> I'm calling a VOTE on releasing these as Apache httpd 2.4.13 GA.
>
> [ ] +1: Good to go
> [ ] +0: meh
> [ ] -1:
On Fri, Jun 5, 2015 at 1:03 AM, Roy T. Fielding wrote:
>
> Hence, we might need a configurable way to ignore a client's ALPN, though I
> doubt that
> "SSLalpn off" is the right way to express that. Likewise, neither is
> SSLAlpnPreference.
> The server protocol(s) preference should be independe
> On Jun 4, 2015, at 9:19 AM, Stefan Eissing
> wrote:
>
> I think we need to clarify some things:
>
> 1. ALPN is initiated by the client. When a client does not send ALPN as part
> of client helo, the SSL alpn callbacks are not invoked and the server does
> not send any ALPN information back.
Yes, thanks :)
On Jun 4, 2015 4:43 PM, "Rob Stradling" wrote:
> s/2.2.13/2.2.30/
>
> ?
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>
s/2.2.13/2.2.30/
?
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
On Thu, Jun 4, 2015 at 6:19 PM, Stefan Eissing
wrote:
> I think we need to clarify some things:
>
> 1. ALPN is initiated by the client. When a client does not send ALPN as part
> of client helo, the SSL alpn callbacks are not invoked and the server does
> not send any ALPN information back. This
On Thu, Jun 4, 2015 at 1:23 PM, Marion & Christophe JAILLET <
christophe.jail...@wanadoo.fr> wrote:
>
> I agree that the wording of the Changelog could be more meaningful.
> Apparently these functions are only used during conf parsing. So, I propose
> to turn is into:
> "Small speed optimization w
Hi,
Skip a few bytes before calling 'strchr' if we know that they can't match.
=
in 'ap_resolve_env', at line 1265 we have:
if (*s == '$') {
if (s[1] == '{' && (e = ap_strchr_c(s, '}'))) {
So, we looking for an en
Not totally lost, it depends on whether the failing output filter is
before or after the http_header filter.
In the latter case, we already sent (part of) the response to the
client, so we must abort.
But in the former case, ap_die() will generate a 500, so to not let
the client without any respons
maybe part of what I am missing is that any output filter failure is a lost
cause, and the mapping happens on the input filter side.
On Thu, Jun 4, 2015 at 1:15 PM Eric Covener wrote:
> I'm a little confused by AP_FILTER_ERROR as used in the handlers we have
> now. Is this return code evolved t
The original thread wrt doubled response is [1] (quite long, sorry).
The rationale is that the handlers should not return an HTTP_* error
blindly when they fail to ap_get_brigade(), because the latter can
return AP_FILTER_ERROR when some input filter responds to the client
by itself (e.g. HTTP fil
I'm a little confused by AP_FILTER_ERROR as used in the handlers we have
now. Is this return code evolved to mean only to issue a 500 error if the
response has not been committed?
/** Returned by any filter if the filter chain encounters an error
* and has already dealt with the error response.
More context at your fingertips without refreshing httpd-2.2 branch,
first...
https://bz.apache.org/bugzilla/show_bug.cgi?id=57832
On Thu, Jun 4, 2015 at 11:26 AM, William A Rowe Jr
wrote:
> [Changing subject, don't mean to hijack the 2.4 activity train]
>
> There is a modestly important patch,
The pre-release test tarballs for Apache httpd 2.4.13 can be found
at the usual place:
http://httpd.apache.org/dev/dist/
I'm calling a VOTE on releasing these as Apache httpd 2.4.13 GA.
[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why.
Vote will last the normal 72 hr
[Changing subject, don't mean to hijack the 2.4 activity train]
There is a modestly important patch, already backported to 2.4.x branch,
that is still sitting in 2.2 status. Could one more committer please review
and vote on that remaining fix?
Because it helps to avert an unintended doubled res
I think we need to clarify some things:
1. ALPN is initiated by the client. When a client does not send ALPN as part of
client helo, the SSL alpn callbacks are not invoked and the server does not
send any ALPN information back. This is different from NPN.
2. SSLAlpnPreference is intended as the
On Thu, Jun 4, 2015 at 10:30 AM, Jim Jagielski wrote:
> Just a reminder... this is about 90mins from 'now'
>
Awesome/thanks!
>
> > On Jun 2, 2015, at 7:32 AM, Jim Jagielski wrote:
> >
> > Although there are some cool things that I'd like to see in
> > 2.4.13, I don't want to hold off any long
Just a reminder... this is about 90mins from 'now'
> On Jun 2, 2015, at 7:32 AM, Jim Jagielski wrote:
>
> Although there are some cool things that I'd like to see in
> 2.4.13, I don't want to hold off any longer (plus, those
> cool things would be good incentive for a 2.4.14 sooner
> rather than
On Thu, Jun 4, 2015 at 2:39 PM, Yann Ylavic wrote:
> On Thu, Jun 4, 2015 at 2:30 PM, Eric Covener wrote:
>>
>>
>> On Thu, Jun 4, 2015 at 8:08 AM Yann Ylavic wrote:
>>>
>>> I think what makes the thing a bit awkward is that the
>>> negotiable/preferred ALNP identifiers (protocols) is configurable
Right, but we can still register our own IDs when httpd will handle
them (with a new directive or by the new module itself).
On Thu, Jun 4, 2015 at 2:26 PM, Jim Jagielski wrote:
> But certainly there are cases were mod_h2 is NOT part of
> the running system, in which case we still need some way
>
On Thu, Jun 4, 2015 at 2:30 PM, Eric Covener wrote:
>
>
> On Thu, Jun 4, 2015 at 8:08 AM Yann Ylavic wrote:
>>
>> I think what makes the thing a bit awkward is that the
>> negotiable/preferred ALNP identifiers (protocols) is configurable in
>> both httpd (SSLAlpnPreference) and mod_h2 (hard coded
>
>
>> If no identifier is registered, mod_ssl won't register the ALPN
>> callback either, so that httpd continues to work without ALPN when not
>> needed.
>>
>
>
I do like that from a backport perspective though.
On Thu, Jun 4, 2015 at 8:08 AM Yann Ylavic wrote:
> I think what makes the thing a bit awkward is that the
> negotiable/preferred ALNP identifiers (protocols) is configurable in
> both httpd (SSLAlpnPreference) and mod_h2 (hard coded).
> The former is only a hint while the latter is the real prop
But certainly there are cases were mod_h2 is NOT part of
the running system, in which case we still need some way
to handle ALNP.
> On Jun 4, 2015, at 8:07 AM, Yann Ylavic wrote:
>
> I think what makes the thing a bit awkward is that the
> negotiable/preferred ALNP identifiers (protocols) is con
I think what makes the thing a bit awkward is that the
negotiable/preferred ALNP identifiers (protocols) is configurable in
both httpd (SSLAlpnPreference) and mod_h2 (hard coded).
The former is only a hint while the latter is the real proposal to the
client (with the fall back to "http/1.1").
Mayb
Can we really do ALPN per vhost?
If this is handled before or at the same time as SNI, then SSLAlpnEnable is
eventually applied per listening address, while H2Engine would make sense even
for multiple hosts at the same ip.
I would say returning some error is a valid response for not enab
34 matches
Mail list logo
