PR 54626 - ldaps not working with microsoft ldapsdk
https://bz.apache.org/bugzilla/show_bug.cgi?id=54626 It looks like this was fixed in trunk a couple of years ago. Is there a reason why it wasn't proposed for a backport to 2.4 or to 2.2? I don't mind managing the patch myself - I'm trying to get someone to stage a system for me to test it, and if no one can, I'm planning on trying to get to it in a couple of weeks - but seems like this would be handy to have fixed in released version. Thanks, Andy
Re: proposed backport, mod_h2 github release
On Wed, Aug 26, 2015 at 1:52 PM, Jim Jagielski j...@jagunet.com wrote: On Aug 26, 2015, at 2:25 PM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: Well, let's have a look at the core changes and discuss specifics. There are only additions. Hooks and functions. And fields added to core_config. Unless some module is messing directly with that, I can see no need for recompilations. I agree with you, looking forward to other reviewers, too. But I might be wrong. Let's review that patch and see. Even so, mod_h2 is hardly the 1st such module that adds fields to the end of core structs... Why are people proposing throwing stop-sticks in our path?? Jim, why are you taking code review as a personal affront? Could we cool it, please?
HTTP Server Project hackathon/BoF in Budapest?
First question, will many of us be present and available during the day Wednesday ahead of the ApacheCon Core content for a hackathon and BoF, or would it be better for these things to happen on Thursday during/in the evening of Core? Bill
Re: Intent to Tag 2.5.0 for -alpha consideration
Ideally, getting mod_h2 into users hands will be MUCH easier by focusing on finishing up the 2.4 backporting... This out of the blue notice to alpha 2.5 seems to me some method to stall or circumvent action in that direction by changing the goalposts... -0.9 On Aug 26, 2015, at 11:21 AM, William A Rowe Jr wr...@rowe-clan.net wrote: I'm planning to tag trunk on 11 Sept to get 2.5.0 and mod_h2 into users hands ASAP and collect feedback on that module ahead of any merges back into the stable 2.4.x branch. Concerns/Questions/Roadblocks/Showstoppers?
Re: Intent to Tag 2.5.0 for -alpha consideration
The faster early adopters can get us bug feedback, the faster the stable and tested module can be backported to 2.4 without experimental warnings, IMO. Nobody is going to do that. No one is going to run 2.5 alpha to test h2 and http/2 when people were ALREADY using and testing h2|http/2 under 2.4 via the module being available under Github. Doing this kinda of aborts the whole concept of bringing in mod_h2 as we did: to allow for http/2 NOW and provide insights on how to best rearchitect 2.6/3.0 for 'even better' http/2 support.
Re: proposed backport, mod_h2 github release
Well, let's have a look at the core changes and discuss specifics. There are only additions. Hooks and functions. And fields added to core_config. Unless some module is messing directly with that, I can see no need for recompilations. But I might be wrong. Let's review that patch and see. //Stefan Am 26.08.2015 um 19:39 schrieb William A Rowe Jr wr...@rowe-clan.net: On Wed, Aug 26, 2015 at 12:08 PM, Jim Jagielski j...@jagunet.com wrote: ?? I can't quite grok what you mean: I'm dubious that we are going to be able to meet the criteria that modules built for httpd 2.4.x will continue to function correctly without recompilation under 2.4+refactoring could you explain?? I'm happy to. I'm not talking about mod_h2 itself, but the API refactoring in core. It seems to me that considering that the h2 module on Github was specific to Apache 2.4, I don't see why we need to add delays or processes to officially add http/2 support, via the h2 module, to 2.4. The whole intent was always that h2 would provide a feedback loop between itself and 2.6/3.0 regarding re-architecturing some aspects, but that doesn't mean we withhold http/2 from 2.4. Of course the h2 module under 2.4 will be different from what is eventually in 2.6/3.0. But so what? I think we are on the same page - hopefully mod_h2 can 'fit' within the current API, or we succeed in working out those API backports such that that modules do not -need- to be aware of the change to the API that happened after they were compiled. The change we made for http trailers was draconian, and forced us to break our agreement in the name of security, and I hope we can avoid repeating the issue. (And we avert that sort of issue in the future with _create accessors for httpd structures.) If the committers decide that twisting the API or mod_h2 itself to shoehorn it into 2.4 is too much, then 2.6 (or 3.0) is still a possibility, and tagging the state of our 2.5.x development as an -alpha should help us start cleaning up the state of trunk/.
Re: svn commit: r1697931 - /httpd/httpd/branches/2.4.x/STATUS
On Wed, Aug 26, 2015 at 8:37 AM, ic...@apache.org wrote: Author: icing Date: Wed Aug 26 13:37:18 2015 New Revision: 1697931 URL: http://svn.apache.org/r1697931 + *) core/mod_ssl: add Protocols/ProtocolsHonorOrder directives and new + protocols hooks to control Upgrade: and ALPN protocol switching. + HTTP_MISDIRECTED_REQUEST addition and handling in mod_ssl + trunk patch: http://svn.apache.org/r1697855 + http://svn.apache.org/r1697339 + http://svn.apache.org/r1696428 + http://svn.apache.org/r1696266 + http://svn.apache.org/r1696264 + http://svn.apache.org/r1695874 + http://svn.apache.org/r1695727 + http://svn.apache.org/r1692516 + http://svn.apache.org/r1692486 + http://svn.apache.org/r1610674 (partial) + http://svn.apache.org/r1685069 +2.4.x patch: https://raw.githubusercontent.com/icing/mod_h2/master/sandbox/httpd/patches/core-protocols.patch I can't see anything that introduces API breakage in this patch set. Well done! With the new API's, a minor MMN bump is necessary. One minor cleanup, a few excess blank lines in include/http_core.h. Looking at +/** + * Get the index of the string in the array or -1 if not found. + * @param array the array the check + * @param s the string to find + * @return index of string in array or -1 + */ +AP_DECLARE(int) ap_array_index(const apr_array_header_t *array, const char *s); with an eye toward apr_array_index, would it be better to start off with a third 'int start' argument (suggested value 0) so that the array is searched from the indicated elt, as arrays are unordered and not defined to contain unique values?
Re: proposed backport, mod_h2 github release
On Aug 26, 2015, at 2:25 PM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: Well, let's have a look at the core changes and discuss specifics. There are only additions. Hooks and functions. And fields added to core_config. Unless some module is messing directly with that, I can see no need for recompilations. But I might be wrong. Let's review that patch and see. Even so, mod_h2 is hardly the 1st such module that adds fields to the end of core structs... Why are people proposing throwing stop-sticks in our path??
Re: proposed backport, mod_h2 github release
On Wed, Aug 26, 2015 at 12:08 PM, Jim Jagielski j...@jagunet.com wrote: ?? I can't quite grok what you mean: I'm dubious that we are going to be able to meet the criteria that modules built for httpd 2.4.x will continue to function correctly without recompilation under 2.4+refactoring could you explain?? I'm happy to. I'm not talking about mod_h2 itself, but the API refactoring in core. It seems to me that considering that the h2 module on Github was specific to Apache 2.4, I don't see why we need to add delays or processes to officially add http/2 support, via the h2 module, to 2.4. The whole intent was always that h2 would provide a feedback loop between itself and 2.6/3.0 regarding re-architecturing some aspects, but that doesn't mean we withhold http/2 from 2.4. Of course the h2 module under 2.4 will be different from what is eventually in 2.6/3.0. But so what? I think we are on the same page - hopefully mod_h2 can 'fit' within the current API, or we succeed in working out those API backports such that that modules do not -need- to be aware of the change to the API that happened after they were compiled. The change we made for http trailers was draconian, and forced us to break our agreement in the name of security, and I hope we can avoid repeating the issue. (And we avert that sort of issue in the future with _create accessors for httpd structures.) If the committers decide that twisting the API or mod_h2 itself to shoehorn it into 2.4 is too much, then 2.6 (or 3.0) is still a possibility, and tagging the state of our 2.5.x development as an -alpha should help us start cleaning up the state of trunk/.
Re: HTTP Server Project hackathon/BoF in Budapest?
On Wed, Aug 26, 2015, 11:43 AM William A Rowe Jr wr...@rowe-clan.net wrote: First question, will many of us be present and available during the day Wednesday ahead of the ApacheCon Core content for a hackathon and BoF, or would it be better for these things to happen on Thursday during/in the evening of Core? Unfortunately I will not be there
Re: proposed backport, mod_h2 github release
?? I can't quite grok what you mean: I'm dubious that we are going to be able to meet the criteria that modules built for httpd 2.4.x will continue to function correctly without recompilation under 2.4+refactoring could you explain?? It seems to me that considering that the h2 module on Github was specific to Apache 2.4, I don't see why we need to add delays or processes to officially add http/2 support, via the h2 module, to 2.4. The whole intent was always that h2 would provide a feedback loop between itself and 2.6/3.0 regarding re-architecturing some aspects, but that doesn't mean we withhold http/2 from 2.4. Of course the h2 module under 2.4 will be different from what is eventually in 2.6/3.0. But so what? On Aug 26, 2015, at 11:20 AM, William A Rowe Jr wr...@rowe-clan.net wrote: On Wed, Aug 26, 2015 at 8:44 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: I just submitted my first backport STATUS update. Hope I did everything ok, otherwise please let me know. For backporting mod_h2 to 2.4.x, I decided to make it in two parts: one is the patch to core/mod_ssl that introduces Protocols. That is now in STATUS. Next would be a patch for modules/http2 which is basically all source files, changes in build and docs. Since there are many new files, does it sense to make a patch for that or do we handle that differently? Also: since there were some people testing the github releases in their own setups, I thought it helpful to let them test the core patch and mod_h2 as it currently is. I made a new release of mod_h2 on github which basically downloads httpd 2.4.16, applies the core patch and builds the mod_h2 copy against it. Hopefully some people take it out for a spin and report back Looking forward to reviewing the code this week! At the moment, I'm dubious that we are going to be able to meet the criteria that modules built for httpd 2.4.x will continue to function correctly without recompilation under 2.4+refactoring, but that's an absolute requirement of our versioning promises. In such a case, 2.6.x (or 3.0.0) would become a top priority. So there's that to consider. I'd like to RM a 2.5.0-alpha release on Friday 11 Sept, that would put the mod_h2 + refactoring into the hands of bleeding edge adopters, ahead of the ApacheCon Core in Budapest. We make no promises about the API between 2.5.0 and 2.5.x and users are expected to recompile their modules while working on that bleed branch.
Re: Intent to Tag 2.5.0 for -alpha consideration
On Wed, Aug 26, 2015 at 12:13 PM, Jim Jagielski j...@jagunet.com wrote: Ideally, getting mod_h2 into users hands will be MUCH easier by focusing on finishing up the 2.4 backporting... This out of the blue notice to alpha 2.5 seems to me some method to stall or circumvent action in that direction by changing the goalposts... If everyone is on the same page about our versioning contract with module authors, the backport thumbs up-or-down decision is going to be clear cut to all of us, right? -0.9 Thank you for your notice of intent to vote against a release, I appreciate the heads-up. Releases cannot be vetoed, of course. The faster early adopters can get us bug feedback, the faster the stable and tested module can be backported to 2.4 without experimental warnings, IMO.
Re: proposed backport, mod_h2 github release
On Wed, Aug 26, 2015 at 10:20 AM, William A Rowe Jr wr...@rowe-clan.net wrote: On Wed, Aug 26, 2015 at 8:44 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: I just submitted my first backport STATUS update. Hope I did everything ok, otherwise please let me know. For backporting mod_h2 to 2.4.x, I decided to make it in two parts: one is the patch to core/mod_ssl that introduces Protocols. That is now in STATUS. Next would be a patch for modules/http2 which is basically all source files, changes in build and docs. Since there are many new files, does it sense to make a patch for that or do we handle that differently? Also: since there were some people testing the github releases in their own setups, I thought it helpful to let them test the core patch and mod_h2 as it currently is. I made a new release of mod_h2 on github which basically downloads httpd 2.4.16, applies the core patch and builds the mod_h2 copy against it. Hopefully some people take it out for a spin and report back Looking forward to reviewing the code this week! At the moment, I'm dubious that we are going to be able to meet the criteria that modules built for httpd 2.4.x will continue to function correctly without recompilation under 2.4+refactoring, but that's an absolute requirement of our versioning promises. In such a case, 2.6.x (or 3.0.0) would become a top priority. So there's that to consider. I'd like to RM a 2.5.0-alpha release on Friday 11 Sept, that would put the mod_h2 + refactoring into the hands of bleeding edge adopters, ahead of the ApacheCon Core in Budapest. We make no promises about the API between 2.5.0 and 2.5.x and users are expected to recompile their modules while working on that bleed branch. Moving feedback back to the backport considerations thread... Btw. if you review the core_protocols.patch and find anything preventing a backport, please let me know asap. I personally would like to avoid a repeat of the ALPN back porting stop due to lack of time to find a proper solution. Of course! The underlying guideline is that all modules built for 2.4.16, blissfully unaware of the 'future' Protocols schema, still just work without recompilation or reconfiguration. If this proves impossible, the backport solution is probably to keep H2Protocols in place on any legacy module, and reserve the generic Protocols for trunk and future releases. ASF mod_ftp is an example of an alternate protocol provider that (as of trunk flavor) should still just work. It happens to be the most convenient for me to compare, but is by no means the only example. I have a couple patches to integrate before proposing a mod_ftp 1.0.1 tag for a release vote, but expect to immediately afterwards start to integrate the proposed Protocols behavior in httpd trunk, and be ahead of the game this round rather than behind in the case of 2.4.x :)
Re: Getting all supported protocols
Yes, that's right - the toolkit does itself decide which protocol is used. However, it decides based on the order of the protocols we pass to it; that is, it will find the first protocol in the list supported by the client and negotiate it. We will order the list ourselves according to Protocols and ProtocolsHonorOrder. The general structure of this toolkit's API is quite different OpenSSL's - it's not callback-based, all we do is pass it a bunch of parameters and then tell it to go ahead with the handshake. I think that may have influenced this API more than NPN. On Wed, Aug 26, 2015 at 11:20 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: Hmm, this was the kind of behaviour of NPN, maybe that influenced the API of that toolkit? I imagine that the toolkit will decide itself then what protocol is negotiated. That would mean that the directive ProtocolsHonorOrder has no longer an effect. Am I right? I do not think that is what we want. //Stefan Am 26.08.2015 um 17:02 schrieb Edward Lu chaos...@gmail.com: I was experimenting with the new support for declaring protocols for e.g. ALPN, but with an SSL toolkit other than openssl. This one wants us to pass the entire list of all the protocols the server supports in advance; later, we can request the one protocol that the toolkit negotiated. It looks like the protocol_propose hook allows us to only grab a subset of the protocols - i.e. it expects us to have the protocol list that the client sends us. I've attached a patch which modifies the protocol_propose hook's interface (documentation), allowing us to get all of the protocols supported by the server. I also modified h2's implementation of the hook to reflect the interface change. Let me know if anyone sees a problem. all_protos.diff green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: modules\http2 - structure initializing.
We don't want C90 specifics, certainly not in 2.4... Strict ANSI.
On Aug 26, 2015, at 11:26 AM, Stefan Eissing stefan.eiss...@greenbytes.de
wrote:
Hi Norm,
I think these type of assignments are part of the C90 standard. I am not sure
we want to support a compiler that cannot cope with that, but I may be to
green to know that. What platform is this on exactly?
//Stefan
Am 26.08.2015 um 00:53 schrieb NormW no...@gknw.net:
G/Morning,
Herewith an svn diff that implements line-by-line initialization of three
structures (no idea if there's a technical term for it) in place of the list
method now used, e.g struct x = { , , , }.
I acknowledge upfront that 'my' somewhat dated compiler cannot handle the
list method, whereas the method portrayed in the diff is totally acceptable
to it.
However, I find the 'list' method less easier to 'read' as the struct
elements are not 'visible', and one has to locate the struct definition
itself to see what is being set to what. The method as illustrated by the
patch is clearer (to my mind) and not affected by the order of the elements
within the primary structure.
Lastly I noticed at least one case recently where my diff 'simplified'
because a struct was changed to the _suggested_ method, with the primary
struct being created by a memset(); perhaps that's a similar change needed
in these cases also?
Regards,
Norm
cw_reqd_chgs.diff
green/bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: Intent to Tag 2.5.0 for -alpha consideration
On Aug 26, 2015, at 1:24 PM, William A Rowe Jr wr...@rowe-clan.net wrote: On Wed, Aug 26, 2015 at 12:13 PM, Jim Jagielski j...@jagunet.com wrote: Ideally, getting mod_h2 into users hands will be MUCH easier by focusing on finishing up the 2.4 backporting... This out of the blue notice to alpha 2.5 seems to me some method to stall or circumvent action in that direction by changing the goalposts... If everyone is on the same page about our versioning contract with module authors, the backport thumbs up-or-down decision is going to be clear cut to all of us, right? -0.9 Thank you for your notice of intent to vote against a release, I appreciate the heads-up. Releases cannot be vetoed, of course. The faster early adopters can get us bug feedback, the faster the stable and tested module can be backported to 2.4 without experimental warnings, IMO. You do know, of course, that the module WAS designed WITH 2.4 IN MIND... That is, the module was created to add http/2 to 2.4.
Re: svn commit: r1696960 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number modules/proxy/mod_proxy_balancer.c
On Wed, Aug 26, 2015 at 3:32 AM, Daniel Ruggeri drugg...@primary.net wrote: On 8/25/2015 10:11 AM, Jim Jagielski wrote: Again, if the slotmem exists and is persisted, the assumption is that THAT is what the admin wants, and when Apache restarts, THAT is the running config they desire. If there are changes to the reverse proxy setup, the assumption must be we are starting from scratch; There are, iirc, a number of places where these kinds of checks are done. Trying to somehow merge a just-changed file config and a running config (based on an older file config with dynamic changes) is nasty and tough to do correctly. This is a common problem with serialization. The persisted config is serialized data of what is in memory. It can only represent the version of the conf file that created it. If you change the conf, deserialization should fail because there could be other material changes that might get in the way. I'm +1 on the idea that using bgrowth space to add stuff via conf+graceful restart should be avoided. Just to be precise ( and maybe give this change a very last chance :p ), this commit does not use arbitrary bgrowth (or growth) space for conf+graceful restarts. The reused slots are still strictly checked against the item_size (unchanged), such that they are garanteed to contain balancers (or members) of the vhost, not any other slot-able object. That's only the check on item_num which is relaxed to verify that it is *greater or equal* to the number of newly loaded balancers (or members), whereas the original check was *strictly equal* here too. My point is that this commit doesn't introduce any issue wrt arbitrary/unrelated/corrupted slots' reuse on restart, we are really talking about free space available strictly for balancers (or members) via the balancer-manager (and the config-file, hopefully). This means that an admin using the balancer-manager (UI) sees the changes, is able to manage all the original or reloaded balancers (or members), and can still add new ones if the slots are not full. IOW, this commit looks compatible (and useful), to me... OTOH, forbidding compatible changes via the config-file looks quite unusual (most people configure httpd via the config-file only, I guess). But hey, I'm not the community :)
Re: HTTP Server Project hackathon/BoF in Budapest?
On Wed, Aug 26, 2015 at 5:29 PM, William A Rowe Jr wr...@rowe-clan.net wrote: First question, will many of us be present and available during the day Wednesday ahead of the ApacheCon Core content for a hackathon and BoF, or would it be better for these things to happen on Thursday during/in the evening of Core? I'll be there on Wednesday, and Thurday too but not the evening. Regards, Yann.
Re: modules\http2 - structure initializing.
G/Morning I think,
As Bill correctly guesses in a following mail, 'my' OS is NetWare and
it's the standard compiler GK has been using for years to build Apache
releases.
And that (Metrowerks CW) (AFAIK) is a C89 legend.
As I noted in my mail, I would hardly expect to hold back tomorrows
http/2 protocol for so dated a horse as NetWare, and if you introduced
coding or functions that NetWare's compiler doesn't support then it's
'game-over' for the old war horse as far as http2 is concerned. For the
moment however I merely suggest an opinion that initializing structures
via a list of individual assignments is a better form to read the code
than what is used at present, and a small, almost irrelevant side effect
of which is that, for now at least, my compiler can keep building http2
for NetWare, with no functional change to the code.
Regards,
Norm
On 27/08/2015 1:26 AM, Stefan Eissing wrote:
Hi Norm,
I think these type of assignments are part of the C90 standard. I am not sure
we want to support a compiler that cannot cope with that, but I may be to green
to know that. What platform is this on exactly?
//Stefan
Am 26.08.2015 um 00:53 schrieb NormW no...@gknw.net:
G/Morning,
Herewith an svn diff that implements line-by-line initialization of three
structures (no idea if there's a technical term for it) in place of the list
method now used, e.g struct x = { , , , }.
I acknowledge upfront that 'my' somewhat dated compiler cannot handle the list
method, whereas the method portrayed in the diff is totally acceptable to it.
However, I find the 'list' method less easier to 'read' as the struct elements
are not 'visible', and one has to locate the struct definition itself to see
what is being set to what. The method as illustrated by the patch is clearer
(to my mind) and not affected by the order of the elements within the primary
structure.
Lastly I noticed at least one case recently where my diff 'simplified' because
a struct was changed to the _suggested_ method, with the primary struct being
created by a memset(); perhaps that's a similar change needed in these cases
also?
Regards,
Norm
cw_reqd_chgs.diff
green/bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
APACHE_CHECK_NGHTTP2
Just a quick observation before backport of mod_h2 is proposed... Moving the macro APACHE_CHECK_NGHTTP2 out of acinclude.m4 into modules/http2/config.m4 lets me build (after a ./buildconf) after simply checking out modules/http2/ from trunk. In terms of ease-of-integration, do we see other modules we expect to utilize libnghttp2, e.g. mod_proxy_http? If so, this probably isn't the right solution, but it makes an interesting and quick stop-gap.
Re: APACHE_CHECK_NGHTTP2
On Wed, Aug 26, 2015 at 6:06 PM, William A Rowe Jr wr...@rowe-clan.net wrote: In terms of ease-of-integration, do we see other modules we expect to utilize libnghttp2, e.g. mod_proxy_http? If so, this probably isn't the right solution, but it makes an interesting and quick stop-gap. I would prefer the mod_h2-only arrangement. I think mod_proxy_http is extremely far away.
Re: modules\http2 - structure initializing.
I will apply the proposed change tomorrow. keep the old horse happy.
//stefan
Am 26.08.2015 um 23:18 schrieb NormW no...@gknw.net:
G/Morning I think,
As Bill correctly guesses in a following mail, 'my' OS is NetWare and it's
the standard compiler GK has been using for years to build Apache releases.
And that (Metrowerks CW) (AFAIK) is a C89 legend.
As I noted in my mail, I would hardly expect to hold back tomorrows http/2
protocol for so dated a horse as NetWare, and if you introduced coding or
functions that NetWare's compiler doesn't support then it's 'game-over' for
the old war horse as far as http2 is concerned. For the moment however I
merely suggest an opinion that initializing structures via a list of
individual assignments is a better form to read the code than what is used at
present, and a small, almost irrelevant side effect of which is that, for now
at least, my compiler can keep building http2 for NetWare, with no functional
change to the code.
Regards,
Norm
On 27/08/2015 1:26 AM, Stefan Eissing wrote:
Hi Norm,
I think these type of assignments are part of the C90 standard. I am not
sure we want to support a compiler that cannot cope with that, but I may be
to green to know that. What platform is this on exactly?
//Stefan
Am 26.08.2015 um 00:53 schrieb NormW no...@gknw.net:
G/Morning,
Herewith an svn diff that implements line-by-line initialization of three
structures (no idea if there's a technical term for it) in place of the
list method now used, e.g struct x = { , , , }.
I acknowledge upfront that 'my' somewhat dated compiler cannot handle the
list method, whereas the method portrayed in the diff is totally acceptable
to it.
However, I find the 'list' method less easier to 'read' as the struct
elements are not 'visible', and one has to locate the struct definition
itself to see what is being set to what. The method as illustrated by the
patch is clearer (to my mind) and not affected by the order of the elements
within the primary structure.
Lastly I noticed at least one case recently where my diff 'simplified'
because a struct was changed to the _suggested_ method, with the primary
struct being created by a memset(); perhaps that's a similar change needed
in these cases also?
Regards,
Norm
cw_reqd_chgs.diff
green/bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: modules\http2 - structure initializing.
Whinnnie!
(eq Equine 'Thanks')
On 27/08/2015 7:31 AM, Stefan Eissing wrote:
I will apply the proposed change tomorrow. keep the old horse happy.
//stefan
Am 26.08.2015 um 23:18 schrieb NormW no...@gknw.net:
G/Morning I think,
As Bill correctly guesses in a following mail, 'my' OS is NetWare and it's the
standard compiler GK has been using for years to build Apache releases.
And that (Metrowerks CW) (AFAIK) is a C89 legend.
As I noted in my mail, I would hardly expect to hold back tomorrows http/2
protocol for so dated a horse as NetWare, and if you introduced coding or
functions that NetWare's compiler doesn't support then it's 'game-over' for the
old war horse as far as http2 is concerned. For the moment however I merely
suggest an opinion that initializing structures via a list of individual
assignments is a better form to read the code than what is used at present, and
a small, almost irrelevant side effect of which is that, for now at least, my
compiler can keep building http2 for NetWare, with no functional change to the
code.
Regards,
Norm
On 27/08/2015 1:26 AM, Stefan Eissing wrote:
Hi Norm,
I think these type of assignments are part of the C90 standard. I am not sure
we want to support a compiler that cannot cope with that, but I may be to green
to know that. What platform is this on exactly?
//Stefan
Am 26.08.2015 um 00:53 schrieb NormW no...@gknw.net:
G/Morning,
Herewith an svn diff that implements line-by-line initialization of three
structures (no idea if there's a technical term for it) in place of the list
method now used, e.g struct x = { , , , }.
I acknowledge upfront that 'my' somewhat dated compiler cannot handle the list
method, whereas the method portrayed in the diff is totally acceptable to it.
However, I find the 'list' method less easier to 'read' as the struct elements
are not 'visible', and one has to locate the struct definition itself to see
what is being set to what. The method as illustrated by the patch is clearer
(to my mind) and not affected by the order of the elements within the primary
structure.
Lastly I noticed at least one case recently where my diff 'simplified' because
a struct was changed to the _suggested_ method, with the primary struct being
created by a memset(); perhaps that's a similar change needed in these cases
also?
Regards,
Norm
cw_reqd_chgs.diff
green/bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: proposed backport, mod_h2 github release
On 8/26/2015 6:44 AM, Stefan Eissing wrote: I just submitted my first backport STATUS update. Hope I did everything ok, otherwise please let me know. For backporting mod_h2 to 2.4.x, I decided to make it in two parts: one is the patch to core/mod_ssl that introduces Protocols. That is now in STATUS. Needs r1693918, other than that all seems ok so far :)
HTTP_MISDIRECTED_REQUEST
Should this exception have a protocol version guard for HTTP/2.0 requests,
and leave the response as HTTP_BAD_REQUEST for HTTP/1.1 and earlier?
@@ -203,6 +204,9 @@
ap_log_error(APLOG_MARK, APLOG_ERR, 0, r-server,
APLOGNO(02032)
Hostname %s provided via SNI and
hostname %s provided
via HTTP are different, servername, host);
+if (r-connection-keepalives 0) {
+return HTTP_MISDIRECTED_REQUEST;
+}
return HTTP_BAD_REQUEST;
}
}
Re: proposed backport, mod_h2 github release
woot!! On Aug 26, 2015, at 9:44 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: I just submitted my first backport STATUS update. Hope I did everything ok, otherwise please let me know. For backporting mod_h2 to 2.4.x, I decided to make it in two parts: one is the patch to core/mod_ssl that introduces Protocols. That is now in STATUS. Next would be a patch for modules/http2 which is basically all source files, changes in build and docs. Since there are many new files, does it sense to make a patch for that or do we handle that differently? The patch could basically be set of SVN merges. Or a giant diff -r -u -N ;) Also: since there were some people testing the github releases in their own setups, I thought it helpful to let them test the core patch and mod_h2 as it currently is. I made a new release of mod_h2 on github which basically downloads httpd 2.4.16, applies the core patch and builds the mod_h2 copy against it. Hopefully some people take it out for a spin and report back. Cheers, Stefan green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
proposed backport, mod_h2 github release
I just submitted my first backport STATUS update. Hope I did everything ok, otherwise please let me know. For backporting mod_h2 to 2.4.x, I decided to make it in two parts: one is the patch to core/mod_ssl that introduces Protocols. That is now in STATUS. Next would be a patch for modules/http2 which is basically all source files, changes in build and docs. Since there are many new files, does it sense to make a patch for that or do we handle that differently? Also: since there were some people testing the github releases in their own setups, I thought it helpful to let them test the core patch and mod_h2 as it currently is. I made a new release of mod_h2 on github which basically downloads httpd 2.4.16, applies the core patch and builds the mod_h2 copy against it. Hopefully some people take it out for a spin and report back. Cheers, Stefan green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Getting all supported protocols
I was experimenting with the new support for declaring protocols for e.g.
ALPN, but with an SSL toolkit other than openssl. This one wants us to pass
the entire list of all the protocols the server supports in advance; later,
we can request the one protocol that the toolkit negotiated.
It looks like the protocol_propose hook allows us to only grab a subset of
the protocols - i.e. it expects us to have the protocol list that the
client sends us. I've attached a patch which modifies the protocol_propose
hook's interface (documentation), allowing us to get all of the protocols
supported by the server. I also modified h2's implementation of the hook to
reflect the interface change.
Let me know if anyone sees a problem.
diff --git a/include/http_protocol.h b/include/http_protocol.h
index 846df2f..b9e0fd4 100644
--- a/include/http_protocol.h
+++ b/include/http_protocol.h
@@ -719,11 +719,15 @@ AP_DECLARE_HOOK(apr_port_t,default_port,(const
request_rec *r))
*
* All hooks are run, unless one returns an error. Proposals may contain
* duplicates. The order in which proposals are added is usually ignored.
+ *
+ * If offers is NULL, then all protocols supported by the server will be
+ * added to the proposals array.
*
* @param c The current connection
* @param r The current request or NULL
* @param s The server/virtual host selected
- * @param offers A list of protocol identifiers offered by the client
+ * @param offers A list of protocol identifiers offered by the client, or
+ * NULL if the client doesn't know in advance
* @param proposals The list of protocol identifiers proposed by the hooks
* @return OK or DECLINED
*/
diff --git a/modules/http2/h2_switch.c b/modules/http2/h2_switch.c
index fd76983..a4cb909 100644
--- a/modules/http2/h2_switch.c
+++ b/modules/http2/h2_switch.c
@@ -105,9 +105,10 @@ static int h2_protocol_propose(conn_rec *c, request_rec *r,
while (*protos) {
/* Add all protocols we know (tls or clear) and that
- * were offered as options for the switch.
+ * were offered as options for the switch. If no
+ * options were offered, add everything.
*/
-if (ap_array_index(offers, *protos) = 0) {
+if (offers == NULL || ap_array_index(offers, *protos) = 0) {
ap_log_cerror(APLOG_MARK, APLOG_TRACE1, 0, c,
proposing protocol '%s', *protos);
APR_ARRAY_PUSH(proposals, const char*) = *protos;
Re: Getting all supported protocols
Hmm, this was the kind of behaviour of NPN, maybe that influenced the API of that toolkit? I imagine that the toolkit will decide itself then what protocol is negotiated. That would mean that the directive ProtocolsHonorOrder has no longer an effect. Am I right? I do not think that is what we want. //Stefan Am 26.08.2015 um 17:02 schrieb Edward Lu chaos...@gmail.com: I was experimenting with the new support for declaring protocols for e.g. ALPN, but with an SSL toolkit other than openssl. This one wants us to pass the entire list of all the protocols the server supports in advance; later, we can request the one protocol that the toolkit negotiated. It looks like the protocol_propose hook allows us to only grab a subset of the protocols - i.e. it expects us to have the protocol list that the client sends us. I've attached a patch which modifies the protocol_propose hook's interface (documentation), allowing us to get all of the protocols supported by the server. I also modified h2's implementation of the hook to reflect the interface change. Let me know if anyone sees a problem. all_protos.diff green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: proposed backport, mod_h2 github release
On Wed, Aug 26, 2015 at 8:44 AM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: I just submitted my first backport STATUS update. Hope I did everything ok, otherwise please let me know. For backporting mod_h2 to 2.4.x, I decided to make it in two parts: one is the patch to core/mod_ssl that introduces Protocols. That is now in STATUS. Next would be a patch for modules/http2 which is basically all source files, changes in build and docs. Since there are many new files, does it sense to make a patch for that or do we handle that differently? Also: since there were some people testing the github releases in their own setups, I thought it helpful to let them test the core patch and mod_h2 as it currently is. I made a new release of mod_h2 on github which basically downloads httpd 2.4.16, applies the core patch and builds the mod_h2 copy against it. Hopefully some people take it out for a spin and report back Looking forward to reviewing the code this week! At the moment, I'm dubious that we are going to be able to meet the criteria that modules built for httpd 2.4.x will continue to function correctly without recompilation under 2.4+refactoring, but that's an absolute requirement of our versioning promises. In such a case, 2.6.x (or 3.0.0) would become a top priority. So there's that to consider. I'd like to RM a 2.5.0-alpha release on Friday 11 Sept, that would put the mod_h2 + refactoring into the hands of bleeding edge adopters, ahead of the ApacheCon Core in Budapest. We make no promises about the API between 2.5.0 and 2.5.x and users are expected to recompile their modules while working on that bleed branch.
Intent to Tag 2.5.0 for -alpha consideration
I'm planning to tag trunk on 11 Sept to get 2.5.0 and mod_h2 into users hands ASAP and collect feedback on that module ahead of any merges back into the stable 2.4.x branch. Concerns/Questions/Roadblocks/Showstoppers?
Re: proposed backport, mod_h2 github release
On Aug 26, 2015, at 2:55 PM, William A Rowe Jr wr...@rowe-clan.net wrote: On Wed, Aug 26, 2015 at 1:52 PM, Jim Jagielski j...@jagunet.com wrote: On Aug 26, 2015, at 2:25 PM, Stefan Eissing stefan.eiss...@greenbytes.de wrote: Well, let's have a look at the core changes and discuss specifics. There are only additions. Hooks and functions. And fields added to core_config. Unless some module is messing directly with that, I can see no need for recompilations. I agree with you, looking forward to other reviewers, too. But I might be wrong. Let's review that patch and see. Even so, mod_h2 is hardly the 1st such module that adds fields to the end of core structs... Why are people proposing throwing stop-sticks in our path?? Jim, why are you taking code review as a personal affront? Could we cool it, please? code review??? None of what you have proposed could be lumped under the heading of code review. Hardly.
Re: APACHE_CHECK_NGHTTP2
On Aug 26, 2015, at 6:19 PM, Eric Covener cove...@gmail.com wrote: On Wed, Aug 26, 2015 at 6:06 PM, William A Rowe Jr wr...@rowe-clan.net wrote: In terms of ease-of-integration, do we see other modules we expect to utilize libnghttp2, e.g. mod_proxy_http? If so, this probably isn't the right solution, but it makes an interesting and quick stop-gap. I would prefer the mod_h2-only arrangement. I think mod_proxy_http is extremely far away. Agreed.
Re: modules\http2 - structure initializing.
Hi Norm,
I think these type of assignments are part of the C90 standard. I am not sure
we want to support a compiler that cannot cope with that, but I may be to green
to know that. What platform is this on exactly?
//Stefan
Am 26.08.2015 um 00:53 schrieb NormW no...@gknw.net:
G/Morning,
Herewith an svn diff that implements line-by-line initialization of three
structures (no idea if there's a technical term for it) in place of the list
method now used, e.g struct x = { , , , }.
I acknowledge upfront that 'my' somewhat dated compiler cannot handle the
list method, whereas the method portrayed in the diff is totally acceptable
to it.
However, I find the 'list' method less easier to 'read' as the struct
elements are not 'visible', and one has to locate the struct definition
itself to see what is being set to what. The method as illustrated by the
patch is clearer (to my mind) and not affected by the order of the elements
within the primary structure.
Lastly I noticed at least one case recently where my diff 'simplified'
because a struct was changed to the _suggested_ method, with the primary
struct being created by a memset(); perhaps that's a similar change needed in
these cases also?
Regards,
Norm
cw_reqd_chgs.diff
green/bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: Intent to Tag 2.5.0 for -alpha consideration
From my side it's a go ahead. We will obviously find bugs in such a new module impacting potentially all requests, but the tests we have are stable. So, I think, getting it into more peoples hands is the way forward. Btw. if you review the core_protocols.patch and find anything preventing a backport, please let me know asap. I personally would like to avoid a repeat of the ALPN back porting stop due to lack of time to find a proper solution. Cheers, Stefan Am 26.08.2015 um 17:21 schrieb William A Rowe Jr wr...@rowe-clan.net: I'm planning to tag trunk on 11 Sept to get 2.5.0 and mod_h2 into users hands ASAP and collect feedback on that module ahead of any merges back into the stable 2.4.x branch. Concerns/Questions/Roadblocks/Showstoppers? green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: modules\http2 - structure initializing.
Netware, I'd presume.
Going forwards on trunk (not breaking 2.4.x) I agree with Norm that the
explicit list is easier for developers to first approach than the list
schema.
The feature I'd really like to see us adopt on trunk is incomplete
structures, which would allow us to break code that believes it knows the
length of an httpd exported structure (it doesn't).
The showstopper I see to 2.6/3.0 GA would be an explicit _create
initializer for all of httpd's exposed types. This would prevent the sort
of breakage caused by our introduction of HttpTrailers late in the 2.4.x
game.
Bill
On Wed, Aug 26, 2015 at 10:26 AM, Stefan Eissing
stefan.eiss...@greenbytes.de wrote:
Hi Norm,
I think these type of assignments are part of the C90 standard. I am not
sure we want to support a compiler that cannot cope with that, but I may be
to green to know that. What platform is this on exactly?
//Stefan
Am 26.08.2015 um 00:53 schrieb NormW no...@gknw.net:
G/Morning,
Herewith an svn diff that implements line-by-line initialization of
three structures (no idea if there's a technical term for it) in place of
the list method now used, e.g struct x = { , , , }.
I acknowledge upfront that 'my' somewhat dated compiler cannot handle
the list method, whereas the method portrayed in the diff is totally
acceptable to it.
However, I find the 'list' method less easier to 'read' as the struct
elements are not 'visible', and one has to locate the struct definition
itself to see what is being set to what. The method as illustrated by the
patch is clearer (to my mind) and not affected by the order of the elements
within the primary structure.
Lastly I noticed at least one case recently where my diff 'simplified'
because a struct was changed to the _suggested_ method, with the primary
struct being created by a memset(); perhaps that's a similar change needed
in these cases also?
Regards,
Norm
cw_reqd_chgs.diff
green/bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: Intent to Tag 2.5.0 for -alpha consideration
On 2015-08-26 17:21, William A Rowe Jr wrote: I'm planning to tag trunk on 11 Sept to get 2.5.0 and mod_h2 into users hands ASAP and collect feedback on that module ahead of any merges back into the stable 2.4.x branch. Concerns/Questions/Roadblocks/Showstoppers? In case there will be a src tar file I'm happy to create a FreeBSD port for 2.5.0. It would be nice to have some small fixes for acinclude.m4 (PR 58126) applied before tagging 2.5.0 to silence warnings about deprecated notations. -- olli
