Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

[Luca Toscano]

2016-07-01 22:31 GMT+02:00 Yann Ylavic :

> On Fri, Jul 1, 2016 at 10:17 PM, William A Rowe Jr 
> wrote:
> > On Fri, Jul 1, 2016 at 2:58 PM, Yann Ylavic 
> wrote:
> >>
> >> On Fri, Jul 1, 2016 at 6:32 PM, Luca Toscano 
> >> wrote:
> >> >
> >> > "The Last-Modified header value '%s' (parsed assuming the GMT
> timezone)
> >> > has
> >> > been replaced with '%s' because considered in the future."
> >>
> >> Looks good to me (maybe "(GMT)" only between parentheses?).
> >>
> >> The original log message can still be switched to a comment, though ;)
> >
> >
> > I'm not fond of the 'assuming' thing, per RFC2616 it *is* defined as GMT.
> >
> > (parsed as GMT, as required)
> >
> > might be a way to phrase that? Other words that came to mind were
> > 'as defined', 'per spec', etc.
> >
> > Showing a value 'datetime (CEST)' (GMT) is unnecessarily confusing.
>

+1, really like the "as required", it is more readable and meaningful.


>
> Hmm, isn't "(CEST)" if there recognized by the parser (so to "correct"
> the compared epoch)?
> If so, this looks more like a bad "Last-Modified" than a future one
> (even if it's the case).
> (Sorry I didn't follow the discussion about this issue).
>
> Anyway, if we can find a timezone string in the header, "(GMT)" alone
> may be indeed confusing, but so is "parsed as GMT" IMHO.
>
> PS: if that has been discussed already, feel free to ignore me, I'll
> go looking at the thread :)
>

We have discussed it briefly in another email but didn't reach a
conclusion, so I am really happy to re-discuss it again. Maybe an example
would clarify what a user will see in the logs.

FCGI script returning the following header (Europe/Paris timezone):

Last-Modified: Sat, 02 Jul 2016 01:49:27 +0200

The current proposed logging (givent a proper LogLevel setting) would be:

[Fri Jul 01 23:49:29.173823 2016] [proxy_fcgi:trace4] [pid 3542:tid
140560966862592] util_script.c(564): [client ::1:52263]   Last-Modified:
Sat, 02 Jul 2016 01:49:27 +0200

[Fri Jul 01 23:49:29.173833 2016] [proxy_fcgi:trace1] [pid 3542:tid
140560966862592] util_script.c(688): [client ::1:52263] The Last-Modified
header value 'Sat, 02 Jul 2016 01:49:27 GMT' (parsed as RFC882/RFC1123
datetime, that assumes the GMT timezone) has been replaced with: 'Fri, 01
Jul 2016 23:49:29 GMT'. An origin server with a clock must not send a
Last-Modified date that is later than the server's time of message
origination.

[Fri Jul 01 23:49:29.173876 2016] [http:trace4] [pid 3542:tid
140560966862592] http_filters.c(835): [client ::1:52263]   Last-Modified:
Fri, 01 Jul 2016 23:49:29 GMT

Notice that the second log (the one that I added) shows both dates in GMT,
no mention of +0200. I didn't find a way to log the original value in the
code section that I changed (probably due to my inexperience), so I relied
on the fact that there is a complete dump of the FCGI headers before it.
This is why I added "parsed as RFC882/RFC1123 datetime, that assumes the
GMT timezone". I also got some feedback from users@ that the log flow was
clear so I proceeded with the commit.

As William wrote in the other thread,
https://tools.ietf.org/html/rfc2616#section-3.3.1 states that the GMT
timezone must be assumed by a datestr parser, and this is exactly what
apr_date_parse_http
seems to be doing.

"The Last-Modified header value '%s' (parsed as GMT date as required) has
been replaced with '%s' because considered in the future." could be a
possible solution. If this is still confusing, we could remove the "parsed
as .." bit.

Thanks!

Regards,

Luca

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

[Yann Ylavic]

On Fri, Jul 1, 2016 at 10:17 PM, William A Rowe Jr  wrote:
> On Fri, Jul 1, 2016 at 2:58 PM, Yann Ylavic  wrote:
>>
>> On Fri, Jul 1, 2016 at 6:32 PM, Luca Toscano 
>> wrote:
>> >
>> > "The Last-Modified header value '%s' (parsed assuming the GMT timezone)
>> > has
>> > been replaced with '%s' because considered in the future."
>>
>> Looks good to me (maybe "(GMT)" only between parentheses?).
>>
>> The original log message can still be switched to a comment, though ;)
>
>
> I'm not fond of the 'assuming' thing, per RFC2616 it *is* defined as GMT.
>
> (parsed as GMT, as required)
>
> might be a way to phrase that? Other words that came to mind were
> 'as defined', 'per spec', etc.
>
> Showing a value 'datetime (CEST)' (GMT) is unnecessarily confusing.

Hmm, isn't "(CEST)" if there recognized by the parser (so to "correct"
the compared epoch)?
If so, this looks more like a bad "Last-Modified" than a future one
(even if it's the case).
(Sorry I didn't follow the discussion about this issue).

Anyway, if we can find a timezone string in the header, "(GMT)" alone
may be indeed confusing, but so is "parsed as GMT" IMHO.

PS: if that has been discussed already, feel free to ignore me, I'll
go looking at the thread :)

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

[William A Rowe Jr]

On Fri, Jul 1, 2016 at 2:58 PM, Yann Ylavic  wrote:

> On Fri, Jul 1, 2016 at 6:32 PM, Luca Toscano 
> wrote:
> >
> > "The Last-Modified header value '%s' (parsed assuming the GMT timezone)
> has
> > been replaced with '%s' because considered in the future."
>
> Looks good to me (maybe "(GMT)" only between parentheses?).
>
> The original log message can still be switched to a comment, though ;)
>

I'm not fond of the 'assuming' thing, per RFC2616 it *is* defined as GMT.

(parsed as GMT, as required)

might be a way to phrase that? Other words that came to mind were
'as defined', 'per spec', etc.

Showing a value 'datetime (CEST)' (GMT) is unnecessarily confusing.

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

[Yann Ylavic]

On Fri, Jul 1, 2016 at 6:32 PM, Luca Toscano  wrote:
>
> "The Last-Modified header value '%s' (parsed assuming the GMT timezone) has
> been replaced with '%s' because considered in the future."

Looks good to me (maybe "(GMT)" only between parentheses?).

The original log message can still be switched to a comment, though ;)

Regards,
Yann.

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

[Luca Toscano]

Hi Yann!

2016-07-01 18:02 GMT+02:00 Yann Ylavic :

> On Fri, Jul 1, 2016 at 5:00 PM,   wrote:
> > Author: elukey
> > Date: Fri Jul  1 15:00:42 2016
> > New Revision: 1750953
> >
> > URL: http://svn.apache.org/viewvc?rev=1750953=rev
> > Log:
> > Fixed typo in log message, wrong RFC mentioned.
> >
> > Modified:
> > httpd/httpd/trunk/server/util_script.c
> >
> > Modified: httpd/httpd/trunk/server/util_script.c
> > URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_script.c?rev=1750953=1750952=1750953=diff
> >
> ==
> > --- httpd/httpd/trunk/server/util_script.c (original)
> > +++ httpd/httpd/trunk/server/util_script.c Fri Jul  1 15:00:42 2016
> > @@ -679,7 +679,7 @@ AP_DECLARE(int) ap_scan_script_header_er
> >  apr_rfc822_date(last_modified_datestr,
> last_modified_date);
> >  ap_log_rerror(SCRIPT_LOG_MARK, APLOG_TRACE1, 0,
> r,
> >"The Last-Modified header value
> '%s' "
> > -  "(parsed as RFC882/RFC1123
> datetime, "
> > +  "(parsed as RFC822/RFC1123
> datetime, "
> >"that assumes the GMT timezone) "
> >"has been replaced with: '%s'. "
> >"An origin server with a clock
> must not send "
>
> This message is possibly too long, you shouldn't cite the RFC, IMHO.
> Something like "The Last-Modified header value '%s' (in the future)
> has been replaced with '%s'" is probably enough.
>

Thanks a lot for the review. This error message is the result of a long
email thread in users@ to make very clear that a Last-Modified value sent
from FCGI/CGI is assumed to be in GMT because of what stated in
RFC822/RFC1123. Maybe something like the following could work better?

"The Last-Modified header value '%s' (parsed assuming the GMT timezone) has
been replaced with '%s' because considered in the future."

Regards,

Luca

Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c

[Yann Ylavic]

On Fri, Jul 1, 2016 at 5:00 PM,   wrote:
> Author: elukey
> Date: Fri Jul  1 15:00:42 2016
> New Revision: 1750953
>
> URL: http://svn.apache.org/viewvc?rev=1750953=rev
> Log:
> Fixed typo in log message, wrong RFC mentioned.
>
> Modified:
> httpd/httpd/trunk/server/util_script.c
>
> Modified: httpd/httpd/trunk/server/util_script.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_script.c?rev=1750953=1750952=1750953=diff
> ==
> --- httpd/httpd/trunk/server/util_script.c (original)
> +++ httpd/httpd/trunk/server/util_script.c Fri Jul  1 15:00:42 2016
> @@ -679,7 +679,7 @@ AP_DECLARE(int) ap_scan_script_header_er
>  apr_rfc822_date(last_modified_datestr, 
> last_modified_date);
>  ap_log_rerror(SCRIPT_LOG_MARK, APLOG_TRACE1, 0, r,
>"The Last-Modified header value '%s' "
> -  "(parsed as RFC882/RFC1123 datetime, "
> +  "(parsed as RFC822/RFC1123 datetime, "
>"that assumes the GMT timezone) "
>"has been replaced with: '%s'. "
>"An origin server with a clock must 
> not send "

This message is possibly too long, you shouldn't cite the RFC, IMHO.
Something like "The Last-Modified header value '%s' (in the future)
has been replaced with '%s'" is probably enough.

Regards,
Yann.
>
>

Re: Apache Benchmark SNI SSL

[Yann Ylavic]

On Fri, Jul 1, 2016 at 4:05 PM, William A Rowe Jr  wrote:
> Yup, no extra steps for correct behavior.
>
> I'd support a ''surpress SNI' flag, and/or an explicit SNI arg, much like
> openssl s_client -- just for testing. But that should be the exceptional
> case.

Done, so that one can also test renegotiations when no SNI is given
but multiple vhosts listening on the same port don't use the same SSL
parameters.

Full patch (vs latest 2.4.x) at
http://home.apache.org/~ylavic/patches/httpd-2.4.x-ab_sni.patch.

Thanks everyone for the feedbacks.

Re: [VOTE] Release Apache httpd 2.4.23 as GA

[Stefan Eissing]

+1
o 14.04.1-Ubuntu x86_64

> Am 30.06.2016 um 19:21 schrieb Jim Jagielski :
> 
> The pre-release test tarballs for Apache httpd 2.4.23 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.23 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: Tagging 2.2.32

[William A Rowe Jr]

On Thu, Jun 30, 2016 at 12:57 PM, William A Rowe Jr 
wrote:

> it looks like 2.2.32 is in a good state for tagging, [...]
>
> There are three patches looking for one more review, and once
> those three are reviewed, I expect to tag later today or early
> tomorrow morning.
>

If anyone is looking at the remaining patches, please holler and
I'll hold off for even later today, otherwise I plan to T by 2pm CDT.

The three remaining patches are fairly straightforward, the first
dodges bad cache entries, the second dodges allocation issues
with openssl engines that we fixed recently on 2.4, and the last
is a very widely requested (and widely tested) fix to allow users
https->proxy which permits opaque proxy authentication, yet
still allows the user agent to CONNECT to the target server.
It would be great to see any (or all) of these make the tag.

Re: Apache Benchmark SNI SSL

[William A Rowe Jr]

Yup, no extra steps for correct behavior.

I'd support a ''surpress SNI' flag, and/or an explicit SNI arg, much like
openssl s_client -- just for testing. But that should be the exceptional
case.
On Jul 1, 2016 8:33 AM, "Reindl Harald"  wrote:



Am 01.07.2016 um 15:23 schrieb Yann Ylavic:

> On Fri, Jul 1, 2016 at 3:17 PM, Yann Ylavic  wrote:
>
>> On Fri, Jul 1, 2016 at 3:02 PM, Reindl Harald 
>> wrote:
>>
>>>
>>> Am 01.07.2016 um 14:41 schrieb Yann Ylavic:
>>>

 The -I does not take any argument, it tells ab to use iether the -H
 "Host: ..." if any, or the host from the given URL otherwise

>>>
>>> but why is there a param needed instead just send the SNI header from the
>>> given URL like any browser does?
>>>
>>
>> You may want to use an IP (or another DNS name) in the URL and still
>> reach the right (Virtual)Host on the server by specifying a -H "Host:
>> ...".
>>
>> The -H "Host:" existed already, and if it's used it has to be taken
>> for the SNI, that's how the server will elect the appropriate
>> VirtualHost if multiple ones listen on the same port.
>>
>
> Oh, I probably misunderstood your remark, you probably meant this
> should be the defaut when TLS is available and used (per -f).
>
> Good point, will look at it
>

exactly - it's all present what is needed to send the host-header and in
case of TLS that's just the same which is needed for the SNI header without
the need to tell "ab" it should use SNI by introducing a new param

Re: Apache Benchmark SNI SSL

[Reindl Harald]

Am 01.07.2016 um 15:23 schrieb Yann Ylavic:

On Fri, Jul 1, 2016 at 3:17 PM, Yann Ylavic  wrote:

On Fri, Jul 1, 2016 at 3:02 PM, Reindl Harald  wrote:


Am 01.07.2016 um 14:41 schrieb Yann Ylavic:


The -I does not take any argument, it tells ab to use iether the -H
"Host: ..." if any, or the host from the given URL otherwise


but why is there a param needed instead just send the SNI header from the
given URL like any browser does?


You may want to use an IP (or another DNS name) in the URL and still
reach the right (Virtual)Host on the server by specifying a -H "Host:
...".

The -H "Host:" existed already, and if it's used it has to be taken
for the SNI, that's how the server will elect the appropriate
VirtualHost if multiple ones listen on the same port.


Oh, I probably misunderstood your remark, you probably meant this
should be the defaut when TLS is available and used (per -f).

Good point, will look at it


exactly - it's all present what is needed to send the host-header and in 
case of TLS that's just the same which is needed for the SNI header 
without the need to tell "ab" it should use SNI by introducing a new param




signature.asc
Description: OpenPGP digital signature

Re: Apache Benchmark SNI SSL

[Yann Ylavic]

On Fri, Jul 1, 2016 at 3:17 PM, Yann Ylavic  wrote:
> On Fri, Jul 1, 2016 at 3:02 PM, Reindl Harald  wrote:
>>
>> Am 01.07.2016 um 14:41 schrieb Yann Ylavic:
>>>
>>> The -I does not take any argument, it tells ab to use iether the -H
>>> "Host: ..." if any, or the host from the given URL otherwise
>>
>> but why is there a param needed instead just send the SNI header from the
>> given URL like any browser does?
>
> You may want to use an IP (or another DNS name) in the URL and still
> reach the right (Virtual)Host on the server by specifying a -H "Host:
> ...".
>
> The -H "Host:" existed already, and if it's used it has to be taken
> for the SNI, that's how the server will elect the appropriate
> VirtualHost if multiple ones listen on the same port.

Oh, I probably misunderstood your remark, you probably meant this
should be the defaut when TLS is available and used (per -f).

Good point, will look at it.

>
> Regards,
> Yann.

Re: Apache Benchmark SNI SSL

[Yann Ylavic]

On Fri, Jul 1, 2016 at 3:02 PM, Reindl Harald  wrote:
>
> Am 01.07.2016 um 14:41 schrieb Yann Ylavic:
>>
>> The -I does not take any argument, it tells ab to use iether the -H
>> "Host: ..." if any, or the host from the given URL otherwise
>
> but why is there a param needed instead just send the SNI header from the
> given URL like any browser does?

You may want to use an IP (or another DNS name) in the URL and still
reach the right (Virtual)Host on the server by specifying a -H "Host:
...".

The -H "Host:" existed already, and if it's used it has to be taken
for the SNI, that's how the server will elect the appropriate
VirtualHost if multiple ones listen on the same port.

Regards,
Yann.

Re: Apache Benchmark SNI SSL

[Reindl Harald]

Am 01.07.2016 um 14:41 schrieb Yann Ylavic:

On Fri, Jul 1, 2016 at 1:44 PM, Pietro Paolini  wrote:


On 1 July 2016 at 11:18, Pietro Paolini  wrote:


Is it correct ? It does not look good to me.

 -while ((status = apr_getopt(opt,
"n:c:t:s:b:T:p:u:v:lrkVhwix:y:z:C:H:P:A:g:X:de:SqB:m:"
+while ((status = apr_getopt(opt,
"n:c:t:s:b:T:p:u:v:lrkVhwixI:y:z:C:H:P:A:g:X:de:SqB:m:"

The x option has lost its argument, the new option you have introduced
uses an argument but the :

+fprintf(stderr, "-I Use TLS Server Name Indication (SNI)
extension\n");

Does not tell that.


Right, it was fixed in a follow up (http://svn.apache.org/r1750855).


That will do the job, as it stands right now it will be working if given a
-I option with a random argument, for example :

./support/ab -I randomstring  -c 1 -n 1 https://whatever/url

The I argument is actually not used.


The -I does not take any argument, it tells ab to use iether the -H
"Host: ..." if any, or the host from the given URL otherwise


but why is there a param needed instead just send the SNI header from 
the given URL like any browser does?






signature.asc
Description: OpenPGP digital signature

Re: Apache Benchmark SNI SSL

[Yann Ylavic]

On Fri, Jul 1, 2016 at 1:44 PM, Pietro Paolini  wrote:
>
> On 1 July 2016 at 11:18, Pietro Paolini  wrote:
>>
>> Is it correct ? It does not look good to me.
>>
>>  -while ((status = apr_getopt(opt,
>> "n:c:t:s:b:T:p:u:v:lrkVhwix:y:z:C:H:P:A:g:X:de:SqB:m:"
>> +while ((status = apr_getopt(opt,
>> "n:c:t:s:b:T:p:u:v:lrkVhwixI:y:z:C:H:P:A:g:X:de:SqB:m:"
>>
>> The x option has lost its argument, the new option you have introduced
>> uses an argument but the :
>>
>> +fprintf(stderr, "-I Use TLS Server Name Indication (SNI)
>> extension\n");
>>
>> Does not tell that.

Right, it was fixed in a follow up (http://svn.apache.org/r1750855).

>
> That will do the job, as it stands right now it will be working if given a
> -I option with a random argument, for example :
>
> ./support/ab -I randomstring  -c 1 -n 1 https://whatever/url
>
> The I argument is actually not used.

The -I does not take any argument, it tells ab to use iether the -H
"Host: ..." if any, or the host from the given URL otherwise.

Regards,
Yann.

Re: Apache Benchmark SNI SSL

[Pietro Paolini]

On 1 July 2016 at 11:18, Pietro Paolini  wrote:

>
>
> On 30 June 2016 at 19:55, Yann Ylavic  wrote:
>
>> On Thu, Jun 30, 2016 at 7:21 PM, Pietro Paolini
>>  wrote:
>> >
>> > I have built the httpd-2-.4.20 tarball but the problem is still there,
>> has
>> > it been fixed in newer version ? is there a workaround for that ?
>>
>> SNI handling just added to ab in http://svn.apache.org/r1750854.
>> It will be part of some future release when accepted by the community,
>> meanwhile maybe you can patch your current release with the commit
>> above.
>>
>> Regards,
>> Yann.
>>
>
> Is it correct ? It does not look good to me.
>
>  -while ((status = apr_getopt(opt,
> "n:c:t:s:b:T:p:u:v:lrkVhwix:y:z:C:H:P:A:g:X:de:SqB:m:"
> +while ((status = apr_getopt(opt,
> "n:c:t:s:b:T:p:u:v:lrkVhwixI:y:z:C:H:P:A:g:X:de:SqB:m:"
>
> The x option has lost its argument, the new option you have introduced
> uses an argument but the :
>
> +fprintf(stderr, "-I Use TLS Server Name Indication (SNI)
> extension\n");
>
> Does not tell that.
>
> The ab tool print the helper and quits without doing anything, I have
> applied the patch on the top of the httpd-2.4.20 though, I am working a bit
> on that, even though given my poor knowledge of the project itself I do not
> think I can't go anywhere but hardcoding:
>
> +SSL_set_tlsext_host_name(c->ssl, "myserverhost");
>
> If I can be of any help - such testing - feel free to drag me in.
>
> Thanks,
> Pietro
>
>
> To fix the patch you just need to
>

 -while ((status = apr_getopt(opt,
"n:c:t:s:b:T:p:u:v:lrkVhwix:y:z:C:H:P:A:g:X:de:SqB:m:"
 +while ((status = apr_getopt(opt,
"n:c:t:s:b:T:p:u:v:lrkVhwiIx:y:z:C:H:P:A:g:X:de:SqB:m:"


That will do the job, as it stands right now it will be working if given a
-I option with a random argument, for example :

./support/ab -I randomstring  -c 1 -n 1 https://whatever/url

The I argument is actually not used.

Cheers,
P.

-- 


Notice:  This email is confidential and may contain copyright material of 
members of the Ocado Group. Opinions and views expressed in this message 
may not necessarily reflect the opinions and views of the members of the 
Ocado Group. 

 

If you are not the intended recipient, please notify us immediately and 
delete all copies of this message. Please note that it is your 
responsibility to scan this message for viruses. 

 

Fetch and Sizzle are trading names of Speciality Stores Limited, a member 
of the Ocado Group.

 

References to the “Ocado Group” are to Ocado Group plc (registered in 
England and Wales with number 7098618) and its subsidiary undertakings (as 
that expression is defined in the Companies Act 2006) from time to time.  
The registered office of Ocado Group plc is Titan Court, 3 Bishops Square, 
Hatfield Business Park, Hatfield, Herts. AL10 9NE.

Re: Apache Benchmark SNI SSL

[Pietro Paolini]

On 30 June 2016 at 19:55, Yann Ylavic  wrote:

> On Thu, Jun 30, 2016 at 7:21 PM, Pietro Paolini
>  wrote:
> >
> > I have built the httpd-2-.4.20 tarball but the problem is still there,
> has
> > it been fixed in newer version ? is there a workaround for that ?
>
> SNI handling just added to ab in http://svn.apache.org/r1750854.
> It will be part of some future release when accepted by the community,
> meanwhile maybe you can patch your current release with the commit
> above.
>
> Regards,
> Yann.
>

Is it correct ? It does not look good to me.

 -while ((status = apr_getopt(opt,
"n:c:t:s:b:T:p:u:v:lrkVhwix:y:z:C:H:P:A:g:X:de:SqB:m:"
+while ((status = apr_getopt(opt,
"n:c:t:s:b:T:p:u:v:lrkVhwixI:y:z:C:H:P:A:g:X:de:SqB:m:"

The x option has lost its argument, the new option you have introduced uses
an argument but the :

+fprintf(stderr, "-I Use TLS Server Name Indication (SNI)
extension\n");

Does not tell that.

The ab tool print the helper and quits without doing anything, I have
applied the patch on the top of the httpd-2.4.20 though, I am working a bit
on that, even though given my poor knowledge of the project itself I do not
think I can't go anywhere but hardcoding:

+SSL_set_tlsext_host_name(c->ssl, "myserverhost");

If I can be of any help - such testing - feel free to drag me in.

Thanks,
Pietro

-- 


Notice:  This email is confidential and may contain copyright material of 
members of the Ocado Group. Opinions and views expressed in this message 
may not necessarily reflect the opinions and views of the members of the 
Ocado Group. 

 

If you are not the intended recipient, please notify us immediately and 
delete all copies of this message. Please note that it is your 
responsibility to scan this message for viruses. 

 

Fetch and Sizzle are trading names of Speciality Stores Limited, a member 
of the Ocado Group.

 

References to the “Ocado Group” are to Ocado Group plc (registered in 
England and Wales with number 7098618) and its subsidiary undertakings (as 
that expression is defined in the Companies Act 2006) from time to time.  
The registered office of Ocado Group plc is Titan Court, 3 Bishops Square, 
Hatfield Business Park, Hatfield, Herts. AL10 9NE.

Re: [VOTE] Release Apache httpd 2.4.23 as GA

[Noel Butler]

Good to go Slackware 14.x

On 01/07/2016 04:02, Jim Jagielski wrote:

+1:
 o OSX 10.11.5, Xcode 7.3.1
 o CentOS 6, 64bit
 o CentOS 7, 64 bit
 o Ubuntu 15.10, 64 bit


On Jun 30, 2016, at 1:21 PM, Jim Jagielski  wrote:

The pre-release test tarballs for Apache httpd 2.4.23 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.23 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!


--
If you have the urge to reply to all rather than reply to list, you best
first read  http://members.ausics.net/qwerty/