Re: TR of 2.2.13 [corresponding to Re: TR of 2.4.13]
s/2.2.13/2.2.30/ ? -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online
Re: mod_deflate was Re: [VOTE] Release Apache httpd 2.4.13 as GA
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) : warning C4003: not enough actual parameters for macro 'APLOGNO' I just rechecked my compilation from near-trunk 6 hours ago, I don't see this. More background, please? gcc or other compiler rev? OS? Revision? I see APLOGNO() in the code. It has been added in http://svn.apache.org/r1669555. Regards, Jan Kaluza It avoids a lot of needless speculation.
Re: mod_deflate was Re: [VOTE] Release Apache httpd 2.4.13 as GA
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 parameters for macro 'APLOGNO' I just rechecked my compilation from near-trunk 6 hours ago, I don't see this. More background, please? gcc or other compiler rev? OS? Revision? It avoids a lot of needless speculation. It's not a compiler thing, doesn't matter what OS. Sorry I didn't mention it's r1669555, my bad! You have the line number in the posted compiler output. However, it's pretty hard to miss as it's in the first stanza of the merge and practically hops in your lap. http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/filters/mod_deflate.c?r1=1661845r2=1669555
mod_deflate was Re: [VOTE] Release Apache httpd 2.4.13 as GA
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'
Re: [VOTE] Release Apache httpd 2.4.13 as GA
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 Will Robinson. And why. Vote will last the normal 72 hrs. NOTE: The *-deps are only there for convenience. Thx! Not a great fan of this ... The SSLCertificateChainFile directive (/usr/local/apache/conf/virtuals/xxx) is deprecated, SSLCertificateFile should be used instead at all, let alone for every single ssl host conf file :) Was any great thought done to the impact for admins who manage 10's or 100's of thousands of domains and the nightmare hell they will be forced to go through when this is eventually dropped, to convert existing confs, not to mention a large number of commercial control panels will also need modification, as well as the inhouse portals and automation scripts as well. For us its easy enough to overcome when I need to, since we really only seem to have 2 cert providers, but others may have a myriad of them and are in for a rough ride if they have a lot of domains. I know its been in changes since 2.4.9 or so, and I know that it likely wont go away before 2.6, but those upgrading to this version will encounter alarms since the output returns unexpected responses, if they have any sort of monitoring on daemon restarts etc, newbie admins will also likely panic thinking it isnt loading at all. I disagree with this removal, it will cause more problems then benefits IMHO, make it a recommendation to use SSLCertificateFile, but not an essential requirement, perhaps log it, and log it only once, not per every domain, not throw them to std out. Apart from that, builds fine with latest APR APR-Util on multiple Slackware platforms and versions. Links: -- [1] http://httpd.apache.org/dev/dist/
Re: mod_deflate was Re: [VOTE] Release Apache httpd 2.4.13 as GA
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 my compilation from near-trunk 6 hours ago, I don't see this. More background, please? gcc or other compiler rev? OS? Revision? It avoids a lot of needless speculation.
Re: mod_deflate was Re: [VOTE] Release Apache httpd 2.4.13 as GA
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? mod_deflate.c(1283) : warning C4003: not enough actual parameters for macro 'APLOGNO' I just rechecked my compilation from near-trunk 6 hours ago, I don't see this. More background, please? gcc or other compiler rev? OS? Revision? It avoids a lot of needless speculation. It's not a compiler thing, doesn't matter what OS. Sorry I didn't mention it's r1669555, my bad! You have the line number in the posted compiler output. However, it's pretty hard to miss as it's in the first stanza of the merge and practically hops in your lap. http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/filters/mod_deflate.c?r1=1661845r2=1669555 This has been fixed in trunk in r1619453. ( APLOGNO(02805) ) CJ
Re: TR of 2.2.30 [corresponding to Re: TR of 2.4.13]
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
Re: ALPN patch comments
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 ALPN information back. This is different from NPN. 2. SSLAlpnPreference is intended as the final word to make a choice when either one ALPN callback proposes many protocols or of several callbacks propose protocols. So, when mod_spdy and mod_h2 are active *and* the client claims to support spdy/3.1 and h2, the SSLAlpnPreference determines what gets chosen and sent to the client. This was not necessary with NPN as in that SSL extension the client was making the choice. 3. Independent of the client proposal, as I read the spec, the server is free to chose any protocol identifier it desires. This might result in the client closing the connection. So, if the client uses ALPN and the server does not want/cannot do/is configured not to support any of the clients proposals, httpd can always send back „http/1.1“ since this is what it always supports. In this light, and correct me if I’m wrong, I see no benefit and only potential harm by introducing a „SSLALpn on|off“ configuration directive. I think the current implementation covers all use cases and if one is missing, please point out the scenario. Ultimately, what we need is a single configuration that defines how the host will respond to connections. I suggest that this should be done on a per-vhost basis if SNI is present, or a per-server basis if not. It should not depend on either ALPN or TLS being present. This needs to be defined by the server admin, not hard coded in the h2 code. We should also have a way for the end of a response to reset the connection to a possibly different set of protocols (i.e., Upgrade), but that's an independent concern. 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 independent of the session/connection protocol. Our internal configuration and use of ALPN should be based on the overall configuration, not a configuration specific to the SSL code. Many configurations won't include ALPN. As with the register once or on every connection optimization, yes, there might be some performance to gain. But I think it is not so straightforward to implement this, as not only the address and port influences this but also the SNI that gets send in the client helo. So, one would have at least to verify that registering an ALPN callback *after* the connection is open and SNI has been received has any effect. I would hope that SNI is received before our connection is established (our connection is the virtual session over TLS, not the TCP connection). There shouldn't be any need to mess with SSL internals within mod_h2. Otherwise, it will be difficult to support h2c and h2 over SSH with the same code. Roy
Re: ALPN patch comments
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 independent of the session/connection protocol. Our internal configuration and use of ALPN should be based on the overall configuration, not a configuration specific to the SSL code. Many configurations won't include ALPN. Maybe we can reuse the Protocol directive then...
Re: TR of 2.2.13 [corresponding to Re: TR of 2.4.13]
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.
*/
#define AP_FILTER_ERROR -102
But now the handlers have this pattern:
status = ap_pass_brigade(r-output_filters, bbout);
if (status != APR_SUCCESS) {
/* no way to know what type of error occurred */
ap_log_rerror(APLOG_MARK, APLOG_DEBUG, status, r,
APLOGNO(01410)
reflector_handler: ap_pass_brigade returned
%i,
status);
return AP_FILTER_ERROR;
}
So we don't actually retain whether some filter really handled the error.
I think in practice this is okay, because the handlers can't make a very
smart decision here anyway.
On Thu, Jun 4, 2015 at 12:44 PM William A Rowe Jr wr...@rowe-clan.net
wrote:
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 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 response in some edge
cases, I consider this one important enough to hold up 2.2 tag for some
more hours.
Bill
On Tue, Jun 2, 2015 at 4:36 PM, William A Rowe Jr wr...@rowe-clan.net
wrote:
On Tue, Jun 2, 2015 at 6: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
rather than later).
I plan to TR 2.4.13 on Thurs, by Noon eastern.
+1, planning to match you with a TR of 2.2.30 on the same timetable.
There is a nominally important last patch in 2.2 STATUS, if a third pair
of eyes have the cycles to review it.
Re: svn commit: r1683044 - /httpd/httpd/trunk/server/core.c
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 parsing Limit, LimitExcept and environment variables Yup, I agree.
Re: TR of 2.2.13 [corresponding to Re: TR of 2.4.13]
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 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.
*/
#define AP_FILTER_ERROR -102
But now the handlers have this pattern:
status = ap_pass_brigade(r-output_filters, bbout);
if (status != APR_SUCCESS) {
/* no way to know what type of error occurred */
ap_log_rerror(APLOG_MARK, APLOG_DEBUG, status, r,
APLOGNO(01410)
reflector_handler: ap_pass_brigade returned
%i,
status);
return AP_FILTER_ERROR;
}
So we don't actually retain whether some filter really handled the error.
I think in practice this is okay, because the handlers can't make a very
smart decision here anyway.
On Thu, Jun 4, 2015 at 12:44 PM William A Rowe Jr wr...@rowe-clan.net
wrote:
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 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 response in some edge
cases, I consider this one important enough to hold up 2.2 tag for some
more hours.
Bill
On Tue, Jun 2, 2015 at 4:36 PM, William A Rowe Jr wr...@rowe-clan.net
wrote:
On Tue, Jun 2, 2015 at 6: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
rather than later).
I plan to TR 2.4.13 on Thurs, by Noon eastern.
+1, planning to match you with a TR of 2.2.30 on the same timetable.
There is a nominally important last patch in 2.2 STATUS, if a third
pair of eyes have the cycles to review it.
Re: TR of 2.2.13 [corresponding to Re: TR of 2.4.13]
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 filter when LimitRequestBody is reached), and the final ap_die() needs to know about this. Hence the fix consists in using ap_map_http_request_error() for any handler failing with ap_get_brigade(), so to translate the apr_status_t to an HTTP error code, taking care of preserving AP_FILTER_ERROR if any. [1] https://www.mail-archive.com/dev@httpd.apache.org/msg61178.html On Thu, Jun 4, 2015 at 6:43 PM, William A Rowe Jr wr...@rowe-clan.net wrote: 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 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 response in some edge cases, I consider this one important enough to hold up 2.2 tag for some more hours. Bill On Tue, Jun 2, 2015 at 4:36 PM, William A Rowe Jr wr...@rowe-clan.net wrote: On Tue, Jun 2, 2015 at 6: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 rather than later). I plan to TR 2.4.13 on Thurs, by Noon eastern. +1, planning to match you with a TR of 2.2.30 on the same timetable. There is a nominally important last patch in 2.2 STATUS, if a third pair of eyes have the cycles to review it.
Re: TR of 2.2.13 [corresponding to Re: TR of 2.4.13]
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 response.
On Thu, Jun 4, 2015 at 7:20 PM, Eric Covener cove...@gmail.com wrote:
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 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.
*/
#define AP_FILTER_ERROR -102
But now the handlers have this pattern:
status = ap_pass_brigade(r-output_filters, bbout);
if (status != APR_SUCCESS) {
/* no way to know what type of error occurred */
ap_log_rerror(APLOG_MARK, APLOG_DEBUG, status, r,
APLOGNO(01410)
reflector_handler: ap_pass_brigade returned
%i,
status);
return AP_FILTER_ERROR;
}
So we don't actually retain whether some filter really handled the error.
I think in practice this is okay, because the handlers can't make a very
smart decision here anyway.
On Thu, Jun 4, 2015 at 12:44 PM William A Rowe Jr wr...@rowe-clan.net
wrote:
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 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 response in some edge
cases, I consider this one important enough to hold up 2.2 tag for some
more hours.
Bill
On Tue, Jun 2, 2015 at 4:36 PM, William A Rowe Jr wr...@rowe-clan.net
wrote:
On Tue, Jun 2, 2015 at 6: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
rather than later).
I plan to TR 2.4.13 on Thurs, by Noon eastern.
+1, planning to match you with a TR of 2.2.30 on the same timetable.
There is a nominally important last patch in 2.2 STATUS, if a third
pair of eyes have the cycles to review it.
Re: svn commit: r1683044 - /httpd/httpd/trunk/server/core.c
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 ending '}', we alreay know that the 2 first
caracters are '$' and '{'
No need to scan them again. They can't match a '}'
So, I proposed to start the scan after these 2 bytes (i.e.
ap_strchr_c(s+2, '}')
s/apr_pstrndup/apr_pstrmemdup/ when applicable.
==
#1) The line after, we apr_pstrndup what was within the '${' and '}'.
We know that (e-s-2) is shorter or equals to the length of '*s'.
So, pstrndup can be replaced by apr_pstrmemdup in order to avoid a
useless call to strlen.
#2) in 'ap_limit_section' line 2139 we have:
const char *endp = ap_strrchr_c(arg, '');
Then we check if the '' has been found at line 2146.
So, we know that (endp - arg) is shorter or equals to the length of
'arg' and that pstrndup can be replaced by apr_pstrmemdup in order to
avoid a useless call to strlen.
Fix a comment typo.
==
resorce -- resource
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 parsing Limit, LimitExcept and
environment variables
Regards,
CJ
Le 03/06/2015 09:05, William A Rowe Jr a écrit :
I tried to reconcile your patch with your svn log entry and I failed.
Could you either correct or explain further?
TIA,
Bill
On Jun 2, 2015 12:40 AM, jaillet...@apache.org
mailto:jaillet...@apache.org wrote:
Author: jailletc36
Date: Tue Jun 2 05:40:57 2015
New Revision: 1683044
URL: http://svn.apache.org/r1683044
Log:
Skip a few bytes before calling 'strchr' if we know that they
can't match.
s/apr_pstrndup/apr_pstrmemdup/ when applicable.
Fix a comment typo.
Modified:
httpd/httpd/trunk/server/core.c
Modified: httpd/httpd/trunk/server/core.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/core.c?rev=1683044r1=1683043r2=1683044view=diff
==
--- httpd/httpd/trunk/server/core.c (original)
+++ httpd/httpd/trunk/server/core.c Tue Jun 2 05:40:57 2015
@@ -1263,8 +1263,8 @@ AP_DECLARE(const char *) ap_resolve_env(
}
if (*s == '$') {
-if (s[1] == '{' (e = ap_strchr_c(s, '}'))) {
-char *name = apr_pstrndup(p, s+2, e-s-2);
+if (s[1] == '{' (e = ap_strchr_c(s+2, '}'))) {
+char *name = apr_pstrmemdup(p, s+2, e-s-2);
word = NULL;
if (server_config_defined_vars)
word =
apr_table_get(server_config_defined_vars, name);
@@ -2147,7 +2147,7 @@ AP_CORE_DECLARE_NONSTD(const char *) ap_
return unclosed_directive(cmd);
}
-limited_methods = apr_pstrndup(cmd-temp_pool, arg, endp - arg);
+limited_methods = apr_pstrmemdup(cmd-temp_pool, arg, endp -
arg);
if (!limited_methods[0]) {
return missing_container_arg(cmd);
@@ -2164,7 +2164,7 @@ AP_CORE_DECLARE_NONSTD(const char *) ap_
return TRACE cannot be controlled by Limit, see
TraceEnable;
}
else if (methnum == M_INVALID) {
-/* method has not been registered yet, but resorce
restriction
+/* method has not been registered yet, but resource
restriction
* is always checked before method handling, so
register it.
*/
methnum = ap_method_register(cmd-pool,
Re: ALPN patch comments
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 ALPN information back. This is different from NPN.
Agreed.
2. SSLAlpnPreference is intended as the final word to make a choice when
either one ALPN callback proposes many protocols or of several callbacks
propose protocols.
I may be missing something but this is not how it is implemented.
If the client sends a protocol which is *not* in SSLAlpnPreference,
but only in the ones proposed by the module (mod_h2), this protocol
will still be accepted.
So SSLAlpnPreference does not have the final word, it will make the
choice between the protocols it knows only.
For this to be the case, we would have to exclude httpd's unknown
client_protos from the proposed_protos, i.e.:
Index: modules/ssl/ssl_engine_kernel.c
===
--- modules/ssl/ssl_engine_kernel.c(revision 1683271)
+++ modules/ssl/ssl_engine_kernel.c(working copy)
@@ -2242,6 +2234,7 @@ int ssl_callback_alpn_select(SSL *ssl,
client_protos = apr_array_make(c-pool, 0, sizeof(char *));
for (i = 0; i inlen; /**/) {
+const char *proto;
unsigned int plen = in[i++];
if (plen + i inlen) {
// someone tries to trick us?
@@ -2249,8 +2242,10 @@ int ssl_callback_alpn_select(SSL *ssl,
ALPN protocol identifier too long);
return SSL_TLSEXT_ERR_ALERT_FATAL;
}
-APR_ARRAY_PUSH(client_protos, char *) =
-apr_pstrndup(c-pool, (const char *)in+i, plen);
+proto = apr_pstrndup(c-pool, (const char *)in+i, plen);
+if (ssl_array_index(ctx-ssl_alpn_pref, proto) = 0) {
+APR_ARRAY_PUSH(client_protos, char *) = proto;
+}
i += plen;
}
--
Otherwise, all the client_protos will be elligible by mod_h2 (only) as
proposed_protos, and the final one be selected with:
+/*
+ * Compare two ALPN protocol proposal. Result is similar to strcmp():
+ * 0 gives same precedence, 0 means proto1 is preferred.
+ */
+static int ssl_cmp_alpn_protos(modssl_ctx_t *ctx,
+ const char *proto1,
+ const char *proto2)
+{
+if (ctx ctx-ssl_alpn_pref) {
+int index1 = ssl_array_index(ctx-ssl_alpn_pref, proto1);
+int index2 = ssl_array_index(ctx-ssl_alpn_pref, proto2);
+if (index2 index1) {
+return (index1 = 0) ? 1 : -1;
+}
+else if (index1 index2) {
+return (index2 = 0) ? -1 : 1;
+}
+}
+/* both have the same index (mabye -1 or no pref configured) and we compare
+ * the names so that spdy3 gets precedence over spdy2. That makes
+ * the outcome at least deterministic. */
+return strcmp((const char *)proto1, (const char *)proto2);
+}
which may bypass SSLAlpnPreference (-1 or no pref configured).
So, when mod_spdy and mod_h2 are active *and* the client claims to support
spdy/3.1 and h2, the SSLAlpnPreference determines what gets chosen and sent
to the client.
Right, provided both are known.
3. Independent of the client proposal, as I read the spec, the server is free
to chose any protocol identifier it desires. This might result in the client
closing the connection. So, if the client uses ALPN and the server does not
want/cannot do/is configured not to support any of the clients proposals,
httpd can always send back „http/1.1“ since this is what it always supports.
Agreed.
In this light, and correct me if I’m wrong, I see no benefit and only
potential harm by introducing a „SSLALpn on|off“ configuration directive. I
think the current implementation covers all use cases and if one is missing,
please point out the scenario.
I also see another issue (already stated in my previous messages): a
client sends an ALPN Hello *without* http/1.1, mod_h2 is not
configured, the connection is refused.
Unless each ALPN compatible MUST (as per RFC) propose http/1.1, we
need a way to disable ALPN on httpd.
Regards,
Yann.
TR of 2.2.13 [corresponding to Re: TR of 2.4.13]
[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 response in some edge cases, I consider this one important enough to hold up 2.2 tag for some more hours. Bill On Tue, Jun 2, 2015 at 4:36 PM, William A Rowe Jr wr...@rowe-clan.net wrote: On Tue, Jun 2, 2015 at 6: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 rather than later). I plan to TR 2.4.13 on Thurs, by Noon eastern. +1, planning to match you with a TR of 2.2.30 on the same timetable. There is a nominally important last patch in 2.2 STATUS, if a third pair of eyes have the cycles to review it.
Re: ALPN patch comments
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 final word to make a choice when either one ALPN callback proposes many protocols or of several callbacks propose protocols. So, when mod_spdy and mod_h2 are active *and* the client claims to support spdy/3.1 and h2, the SSLAlpnPreference determines what gets chosen and sent to the client. This was not necessary with NPN as in that SSL extension the client was making the choice. 3. Independent of the client proposal, as I read the spec, the server is free to chose any protocol identifier it desires. This might result in the client closing the connection. So, if the client uses ALPN and the server does not want/cannot do/is configured not to support any of the clients proposals, httpd can always send back „http/1.1“ since this is what it always supports. In this light, and correct me if I’m wrong, I see no benefit and only potential harm by introducing a „SSLALpn on|off“ configuration directive. I think the current implementation covers all use cases and if one is missing, please point out the scenario. As with the register once or on every connection optimization, yes, there might be some performance to gain. But I think it is not so straightforward to implement this, as not only the address and port influences this but also the SNI that gets send in the client helo. So, one would have at least to verify that registering an ALPN callback *after* the connection is open and SNI has been received has any effect. cheers, Stefan Am 04.06.2015 um 14:52 schrieb Yann Ylavic ylavic@gmail.com: 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 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 it would be cleaner to let the modules register the ALPN identifiers (at configure time, with another optional function), and get rid of SSLAlpnPreference on mod_ssl side. 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 think we need SSLAlpnPreference any time modules register ALPN protocols, otherwise the admin has no control over whih is negotiated. I don't think we should rip it out. OK, so it should probably be renammed SSLAlpnIDs or similar, and be more than just a hint when configured (i.e. refuse connection if no client ALPN ID matches). I meant fall back to http/1.1 still, not refuse the connection. green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
[VOTE] Release Apache httpd 2.4.13 as GA
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 hrs. NOTE: The *-deps are only there for convenience. Thx!
Re: TR of 2.2.13 [corresponding to Re: TR of 2.4.13]
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 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 response in some edge cases, I consider this one important enough to hold up 2.2 tag for some more hours. Bill On Tue, Jun 2, 2015 at 4:36 PM, William A Rowe Jr wr...@rowe-clan.net wrote: On Tue, Jun 2, 2015 at 6: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 rather than later). I plan to TR 2.4.13 on Thurs, by Noon eastern. +1, planning to match you with a TR of 2.2.30 on the same timetable. There is a nominally important last patch in 2.2 STATUS, if a third pair of eyes have the cycles to review it.
Re: TR of 2.4.13
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 want to hold off any longer (plus, those cool things would be good incentive for a 2.4.14 sooner rather than later). I plan to TR 2.4.13 on Thurs, by Noon eastern. -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: TR of 2.4.13
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 rather than later). I plan to TR 2.4.13 on Thurs, by Noon eastern.
RE: ALPN patch comments
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 enabling H2Engine on a VHost, while still handling ALPN when explicitly disabled is not. Bert From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] Sent: woensdag 3 juni 2015 22:20 To: dev@httpd.apache.org Subject: Re: ALPN patch comments That is why mod_h2 allowe H2Engine on|off on base server and vhosts. If I understand you correctly, this does what you ask for. //Stefan Am 03.06.2015 um 19:45 schrieb William A Rowe Jr wr...@rowe-clan.net mailto:wr...@rowe-clan.net : On Wed, Jun 3, 2015 at 8:43 AM, Stefan Eissing stefan.eiss...@greenbytes.de mailto:stefan.eiss...@greenbytes.de wrote: Hmm, personally, I do not like redundant configurations. If someone configures a module, like mod_h2, to be enabled (H2Engine on), she could expect the module to take all the necessary steps. So I am no fan of a „SSLAlpnEnable“. The reason boils down to vhosts and interop. If someone does not wish for a specific vhost (perhaps interacting with bad clients, or created for backwards compatibility) to respond with a feature, it is useful to have a fine-grained toggle. The default -could- be 'enabled', although this probably should not happen on the stable/maintenance branches, but simply on the future release branch, to avoid surprises. OpenSSL does the wrong thing in some cases with respect to TLS/SNI and my current patch development - in some respect - is backing out that callback change for customers who have been burned by this specific nonsense. You should reconsider absolutist behaviors, because they make it much harder for people to inject 'experimental' behaviors into specific hosts.
Re: ALPN patch comments
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 it would be cleaner to let the modules register the ALPN identifiers (at configure time, with another optional function), and get rid of SSLAlpnPreference on mod_ssl side. 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. WDYT? On Thu, Jun 4, 2015 at 12:45 PM, Bert Huijben b...@qqmail.nl wrote: 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 enabling H2Engine on a VHost, while still handling ALPN when explicitly disabled is not. Bert From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] Sent: woensdag 3 juni 2015 22:20 To: dev@httpd.apache.org Subject: Re: ALPN patch comments That is why mod_h2 allowe H2Engine on|off on base server and vhosts. If I understand you correctly, this does what you ask for. //Stefan Am 03.06.2015 um 19:45 schrieb William A Rowe Jr wr...@rowe-clan.net: On Wed, Jun 3, 2015 at 8:43 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: Hmm, personally, I do not like redundant configurations. If someone configures a module, like mod_h2, to be enabled (H2Engine on), she could expect the module to take all the necessary steps. So I am no fan of a „SSLAlpnEnable“. The reason boils down to vhosts and interop. If someone does not wish for a specific vhost (perhaps interacting with bad clients, or created for backwards compatibility) to respond with a feature, it is useful to have a fine-grained toggle. The default -could- be 'enabled', although this probably should not happen on the stable/maintenance branches, but simply on the future release branch, to avoid surprises. OpenSSL does the wrong thing in some cases with respect to TLS/SNI and my current patch development - in some respect - is backing out that callback change for customers who have been burned by this specific nonsense. You should reconsider absolutist behaviors, because they make it much harder for people to inject 'experimental' behaviors into specific hosts.
Re: ALPN patch comments
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 (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 it would be cleaner to let the modules register the ALPN identifiers (at configure time, with another optional function), and get rid of SSLAlpnPreference on mod_ssl side. 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. WDYT? On Thu, Jun 4, 2015 at 12:45 PM, Bert Huijben b...@qqmail.nl wrote: 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 enabling H2Engine on a VHost, while still handling ALPN when explicitly disabled is not. Bert From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] Sent: woensdag 3 juni 2015 22:20 To: dev@httpd.apache.org Subject: Re: ALPN patch comments That is why mod_h2 allowe H2Engine on|off on base server and vhosts. If I understand you correctly, this does what you ask for. //Stefan Am 03.06.2015 um 19:45 schrieb William A Rowe Jr wr...@rowe-clan.net: On Wed, Jun 3, 2015 at 8:43 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: Hmm, personally, I do not like redundant configurations. If someone configures a module, like mod_h2, to be enabled (H2Engine on), she could expect the module to take all the necessary steps. So I am no fan of a „SSLAlpnEnable“. The reason boils down to vhosts and interop. If someone does not wish for a specific vhost (perhaps interacting with bad clients, or created for backwards compatibility) to respond with a feature, it is useful to have a fine-grained toggle. The default -could- be 'enabled', although this probably should not happen on the stable/maintenance branches, but simply on the future release branch, to avoid surprises. OpenSSL does the wrong thing in some cases with respect to TLS/SNI and my current patch development - in some respect - is backing out that callback change for customers who have been burned by this specific nonsense. You should reconsider absolutist behaviors, because they make it much harder for people to inject 'experimental' behaviors into specific hosts.
Re: ALPN patch comments
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.
Re: ALPN patch comments
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 is the real proposal to the client (with the fall back to http/1.1). Maybe it would be cleaner to let the modules register the ALPN identifiers (at configure time, with another optional function), and get rid of SSLAlpnPreference on mod_ssl side. 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 think we need SSLAlpnPreference any time modules register ALPN protocols, otherwise the admin has no control over whih is negotiated. I don't think we should rip it out.
Re: ALPN patch comments
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 (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 it would be cleaner to let the modules register the ALPN identifiers (at configure time, with another optional function), and get rid of SSLAlpnPreference on mod_ssl side. 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 think we need SSLAlpnPreference any time modules register ALPN protocols, otherwise the admin has no control over whih is negotiated. I don't think we should rip it out. OK, so it should probably be renammed SSLAlpnIDs or similar, and be more than just a hint when configured (i.e. refuse connection if no client ALPN ID matches). Modules could then, the other way around, retrieve that list with an optional fn, and do nothing if none matches their aptitude...
Re: ALPN patch comments
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 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 (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 it would be cleaner to let the modules register the ALPN identifiers (at configure time, with another optional function), and get rid of SSLAlpnPreference on mod_ssl side. 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. WDYT? On Thu, Jun 4, 2015 at 12:45 PM, Bert Huijben b...@qqmail.nl wrote: 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 enabling H2Engine on a VHost, while still handling ALPN when explicitly disabled is not. Bert From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] Sent: woensdag 3 juni 2015 22:20 To: dev@httpd.apache.org Subject: Re: ALPN patch comments That is why mod_h2 allowe H2Engine on|off on base server and vhosts. If I understand you correctly, this does what you ask for. //Stefan Am 03.06.2015 um 19:45 schrieb William A Rowe Jr wr...@rowe-clan.net: On Wed, Jun 3, 2015 at 8:43 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: Hmm, personally, I do not like redundant configurations. If someone configures a module, like mod_h2, to be enabled (H2Engine on), she could expect the module to take all the necessary steps. So I am no fan of a „SSLAlpnEnable“. The reason boils down to vhosts and interop. If someone does not wish for a specific vhost (perhaps interacting with bad clients, or created for backwards compatibility) to respond with a feature, it is useful to have a fine-grained toggle. The default -could- be 'enabled', although this probably should not happen on the stable/maintenance branches, but simply on the future release branch, to avoid surprises. OpenSSL does the wrong thing in some cases with respect to TLS/SNI and my current patch development - in some respect - is backing out that callback change for customers who have been burned by this specific nonsense. You should reconsider absolutist behaviors, because they make it much harder for people to inject 'experimental' behaviors into specific hosts.
Re: ALPN patch comments
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 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 it would be cleaner to let the modules register the ALPN identifiers (at configure time, with another optional function), and get rid of SSLAlpnPreference on mod_ssl side. 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 think we need SSLAlpnPreference any time modules register ALPN protocols, otherwise the admin has no control over whih is negotiated. I don't think we should rip it out. OK, so it should probably be renammed SSLAlpnIDs or similar, and be more than just a hint when configured (i.e. refuse connection if no client ALPN ID matches). I meant fall back to http/1.1 still, not refuse the connection.
