s/2.2.13/2.2.30/
?
--
Rob Stradling
Senior Research Development Scientist
COMODO - Creating Trust Online
On 06/05/2015 07:01 AM, William A Rowe Jr wrote:
On Thu, Jun 4, 2015 at 10:47 PM, Gregg Smith g...@gknw.net
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) :
On 6/4/2015 10:01 PM, William A Rowe Jr wrote:
On Thu, Jun 4, 2015 at 10:47 PM, Gregg Smithg...@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: not enough actual
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: Danger
On Thu, Jun 4, 2015 at 10:47 PM, Gregg Smith 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: not enough actual parameters for
macro 'APLOGNO'
I just rechecked
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 Smithg...@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?
Yes, thanks :)
On Jun 4, 2015 4:43 PM, Rob Stradling rob.stradl...@comodo.com wrote:
s/2.2.13/2.2.30/
?
--
Rob Stradling
Senior Research Development Scientist
COMODO - Creating Trust Online
On Jun 4, 2015, at 9:19 AM, Stefan Eissing stefan.eiss...@greenbytes.de
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
On Fri, Jun 5, 2015 at 1:03 AM, Roy T. Fielding field...@gbiv.com 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
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
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 when
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 cove...@gmail.com wrote:
I'm a little confused by AP_FILTER_ERROR as used in the handlers we have
now. Is this
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
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
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
On Thu, Jun 4, 2015 at 6:19 PM, Stefan Eissing
stefan.eiss...@greenbytes.de 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
[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
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 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
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 wr...@rowe-clan.net
wrote:
[Changing subject, don't mean to hijack the 2.4 activity train]
There is a modestly
On Thu, Jun 4, 2015 at 10:30 AM, Jim Jagielski j...@jagunet.com wrote:
Just a reminder... this is about 90mins from 'now'
Awesome/thanks!
On Jun 2, 2015, at 7:32 AM, Jim Jagielski j...@jagunet.com wrote:
Although there are some cool things that I'd like to see in
2.4.13, I don't
Just a reminder... this is about 90mins from 'now'
On Jun 2, 2015, at 7:32 AM, Jim Jagielski j...@jagunet.com 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
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
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).
Maybe
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 ylavic@gmail.com wrote:
I think what makes the thing a bit awkward is that the
negotiable/preferred ALNP identifiers
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 ylavic@gmail.com 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
On Thu, Jun 4, 2015 at 2:30 PM, Eric Covener cove...@gmail.com wrote:
On Thu, Jun 4, 2015 at 8:08 AM Yann Ylavic ylavic@gmail.com wrote:
I think what makes the thing a bit awkward is that the
negotiable/preferred ALNP identifiers (protocols) is configurable in
both httpd
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 j...@jagunet.com wrote:
But certainly there are cases were mod_h2 is NOT part of
the running system, in which case we still
On Thu, Jun 4, 2015 at 2:39 PM, Yann Ylavic ylavic@gmail.com wrote:
On Thu, Jun 4, 2015 at 2:30 PM, Eric Covener cove...@gmail.com wrote:
On Thu, Jun 4, 2015 at 8:08 AM Yann Ylavic ylavic@gmail.com wrote:
I think what makes the thing a bit awkward is that the
negotiable/preferred
31 matches
Mail list logo
