Re: Mergine of Multiple Cookie Headers

[Joseph Schaefer]

Most cookies don't use quoted values tho, and I'm not sure what this does for 
those.

Sent from my iPhone

> On Jun 30, 2016, at 10:51 AM, Yann Ylavic  wrote:
> 
> On Thu, Jun 30, 2016 at 4:46 PM, Rainer Canavan
>  wrote:
>> On Wed, Jun 29, 2016 at 10:27 AM, Yann Ylavic  wrote:
>>> 
>>> RequestHeader edit* Cookie
>>> ([^=;,]++)(="(?:[^"].)*+[^"]*+"|[^;,]*)?+[;,] $1$2; early
>> 
>> I have to admit that I'd never have thought of using mod_headers. Both
>> solutions work as expected, but Yann's solution looks somewhat more
>> robust to me, so I think I'll go with that.
> 
> I think I forgot a .*+ above to really eat the quoted escapes, so I'd
> rather propose:
> RequestHeader edit* Cookie
> ([^=;,]++)(="(?:[^"]*+.)*+[^"]*+"|[^;,]*)?+[;,] $1$2; early
> 
> Regards,
> Yann.

Re: Apache Benchmark SNI SSL

[Reindl Harald]

Am 30.06.2016 um 20:55 schrieb Yann Ylavic:

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


oh *that* explains why it's impossible to "ab" a apache trafficserver 
target (running as reverse proxy) while it just *looked like* it works 
on httpd-sni vhosts while likely do the benchmark always on the default host




signature.asc
Description: OpenPGP digital signature

Re: Apache Benchmark SNI SSL

[Yann Ylavic]

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.

Re: svn commit: r1750779 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_kernel.c

[Ruediger Pluem]

On 06/30/2016 07:07 PM, Stefan Eissing wrote:
> 
>> Am 30.06.2016 um 17:55 schrieb Yann Ylavic :
>>
>> On Thu, Jun 30, 2016 at 5:38 PM, Stefan Eissing
>>  wrote:
>>> We now set exactly the same callback right before in line 709. If we had 
>>> more than one callback, we would not have to specify NULL, but restore any 
>>> previous callback there was, right?
>>
>> Actually NULL preserves the current callback, so once we've set one
>> (or the default) at global/connection init time, if we use NULL
>> everywhere else we can preserve it (patch proposed in my previous
>> message).
> 
> What I meant was: we would need to reset the callback that was in place 
> before line 709. The "NULL=ignore the parameter" will not suffice in case we 
> have more than one callback.

Fair enough. I didn't look at line 709 but only at line 804. So we handle 
things differently in both cases. I would like
to see a consistent approach. But nothing terribly urgent or important. As said 
the patch works anyway in our case.

Regards

Rüdiger

Re: [VOTE] Release Apache httpd 2.4.23 as GA

[Jim Jagielski]

+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!

Tagging 2.2.32

[William A Rowe Jr]

Since it's usually easier to do these things in pairs or groups,
it looks like 2.2.32 is in a good state for tagging, and to
especially reiterate the message in both the 2.4.x and 2.2.x
Announcement that 2.2 is really, really going away soon.

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.

With luck, our timing aligns with the 2.4.23 candidate and we
can all take a step back from the Tag/Test/Release script for
a few weeks :)

Cheers,

Bill

Re: Apache Benchmark SNI SSL

[Stefan Eissing]

You might want to try adding the ppa by ondrej to your apt-get source and 
install a newer apache and opensll from there. That should give you an ab with 
openssl 1.0.2 linked.

 https://launchpad.net/%7Eondrej/+archive/ubuntu/apache2

> Am 30.06.2016 um 19:21 schrieb Pietro Paolini :
> 
> Hi all,
> 
> I apologise in advance, if this is not the right place where to post such 
> question.
> I have tried to use the ab tool which comes with the apache package of my 
> Ubuntu 14.04 distro to stress test a web server, such server lies behind a 
> CDN and the use of the TLS Server Name Indication is required.
> 
> Unfortunately my ab binary does not cope well with that and this is what I 
> get:
> 
> dpkg -l *apache2-utils*
> 
>  apache2-utils   2.4.7-1ubuntu4.1 amd64
> 
> 
> Benchmarking api.sit.cymesfood.osp.tech (be patient)...SSL handshake failed 
> (1).
> 139742942701280:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 
> alert h
> andshake failure:s23_clnt.c:770:  
>  
> ..done
> 
> Googling the problem I found people with similar issues who have re-built the 
> apache source tarball after having applied some patches or manually having 
> modified the code.
> 
> https://blogs.oracle.com/meena/entry/apachebench_ab_and_sni
> 
> Such guide is based on httpd-2.3.11-beta
> 
> The issue with that is that I do not have much diff context to see where the 
> changes should be applied and the starting tarball is different httpd-2.3.11 
> vs httpd-2.4.20, furthermore  I though that asking directly the community 
> involved in the project could give me a better idea about what's needed.
> 
> 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 ?
> 
> 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.

Apache Benchmark SNI SSL

[Pietro Paolini]

Hi all,

I apologise in advance, if this is not the right place where to post such
question.
I have tried to use the ab tool which comes with the apache package of my
Ubuntu 14.04 distro to stress test a web server, such server lies behind a
CDN and the use of the TLS Server Name Indication is required.

Unfortunately my ab binary does not cope well with that and this is what I
get:

dpkg -l *apache2-utils*

 apache2-utils   2.4.7-1ubuntu4.1 amd64


Benchmarking api.sit.cymesfood.osp.tech (be patient)...SSL handshake failed
(1).
139742942701280:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert h
andshake
failure:s23_clnt.c:770:
..done

Googling the problem I found people with similar issues who have re-built
the apache source tarball after having applied some patches or manually
having modified the code.

https://blogs.oracle.com/meena/entry/apachebench_ab_and_sni

Such guide is based on httpd-2.3.11-beta

The issue with that is that I do not have much diff context to see where
the changes should be applied and the starting tarball is different
httpd-2.3.11 vs httpd-2.4.20, furthermore  I though that asking directly
the community involved in the project could give me a better idea about
what's needed.

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 ?

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.

[VOTE] Release Apache httpd 2.4.23 as GA

[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: svn commit: r1750779 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_kernel.c

[Stefan Eissing]

> Am 30.06.2016 um 17:55 schrieb Yann Ylavic :
> 
> On Thu, Jun 30, 2016 at 5:38 PM, Stefan Eissing
>  wrote:
>> We now set exactly the same callback right before in line 709. If we had 
>> more than one callback, we would not have to specify NULL, but restore any 
>> previous callback there was, right?
> 
> Actually NULL preserves the current callback, so once we've set one
> (or the default) at global/connection init time, if we use NULL
> everywhere else we can preserve it (patch proposed in my previous
> message).

What I meant was: we would need to reset the callback that was in place before 
line 709. The "NULL=ignore the parameter" will not suffice in case we have more 
than one callback.

I have not digested the patch completely, but fully agree that changing things 
should be delayed until the time we actually have decided to go for it.

-Stefan

PS. JFTR, the NULL handling here is whacky by OpenSSL. But, of course, it is 
what it is...

Re: svn commit: r1750779 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_kernel.c

[Dirk-Willem van Gulik]

That is my reading as well - +1.

> On 30 Jun 2016, at 18:38, Jim Jagielski  wrote:
> 
> +1
> 
>> On Jun 30, 2016, at 11:38 AM, Stefan Eissing  
>> wrote:
>> 
>> We now set exactly the same callback right before in line 709. If we had 
>> more than one callback, we would not have to specify NULL, but restore any 
>> previous callback there was, right?
>> 
>> But that is all just theoretical, as You and Yann already stated.
>> 
>>> Am 30.06.2016 um 17:26 schrieb Yann Ylavic :
>>> 
>>> On Thu, Jun 30, 2016 at 5:05 PM, Ruediger Pluem  wrote:
 
 Is there a reson why we use ssl_callback_SSLVerify instead of NULL like we 
 do in asimilar situation below?
 IMHO we do not want to change the callback here to whatever it may set.
 I agree that in practice there won't be any difference right now, since we 
 only have one callback.
>>> 
>>> I agree that if/when we have multiple callback possibilities, we
>>> should set NULL here, but also above where we force the new mode.
>>> 
>>> Nothing to worry about for now, though.
>>> 
>>> Regards,
>>> Yann.
>> 
> 
> 

Re: svn commit: r1750779 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_kernel.c

[Jim Jagielski]

+1

> On Jun 30, 2016, at 11:38 AM, Stefan Eissing  
> wrote:
> 
> We now set exactly the same callback right before in line 709. If we had more 
> than one callback, we would not have to specify NULL, but restore any 
> previous callback there was, right?
> 
> But that is all just theoretical, as You and Yann already stated.
> 
>> Am 30.06.2016 um 17:26 schrieb Yann Ylavic :
>> 
>> On Thu, Jun 30, 2016 at 5:05 PM, Ruediger Pluem  wrote:
>>> 
>>> Is there a reson why we use ssl_callback_SSLVerify instead of NULL like we 
>>> do in asimilar situation below?
>>> IMHO we do not want to change the callback here to whatever it may set.
>>> I agree that in practice there won't be any difference right now, since we 
>>> only have one callback.
>> 
>> I agree that if/when we have multiple callback possibilities, we
>> should set NULL here, but also above where we force the new mode.
>> 
>> Nothing to worry about for now, though.
>> 
>> Regards,
>> Yann.
> 

Re: svn commit: r1750779 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_kernel.c

[Yann Ylavic]

On Thu, Jun 30, 2016 at 5:38 PM, Stefan Eissing
 wrote:
> We now set exactly the same callback right before in line 709. If we had more 
> than one callback, we would not have to specify NULL, but restore any 
> previous callback there was, right?

Actually NULL preserves the current callback, so once we've set one
(or the default) at global/connection init time, if we use NULL
everywhere else we can preserve it (patch proposed in my previous
message).

>
> But that is all just theoretical, as You and Yann already stated.

Yes, this worked already like this in previous trunk and 2.4.x, even
for the existing NULL below since we forcibly set it first.

Re: svn commit: r1750779 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_kernel.c

[Yann Ylavic]

On Thu, Jun 30, 2016 at 5:26 PM, Yann Ylavic  wrote:
> On Thu, Jun 30, 2016 at 5:05 PM, Ruediger Pluem  wrote:
>>
>> Is there a reson why we use ssl_callback_SSLVerify instead of NULL like we 
>> do in asimilar situation below?
>> IMHO we do not want to change the callback here to whatever it may set.
>> I agree that in practice there won't be any difference right now, since we 
>> only have one callback.
>
> I agree that if/when we have multiple callback possibilities, we
> should set NULL here, but also above where we force the new mode.

Also note that we could avoid this SSL_set_verify() dance in
ssl_hook_Access() with something like the attached patch, which moves
it just before the actual renegotiation.

The new AP_CONN_CLOSE are to help core HTTP with connections we know
are not unrecoverable.

>
> Regards,
> Yann.
Index: modules/ssl/ssl_engine_kernel.c
===
--- modules/ssl/ssl_engine_kernel.c	(revision 1750805)
+++ modules/ssl/ssl_engine_kernel.c	(working copy)
@@ -682,11 +682,12 @@ int ssl_hook_Access(request_rec *r)
  * verification but at least skip the I/O-intensive renegotiation
  * handshake.
  */
+verify = SSL_get_verify_mode(ssl);
 if ((dc->nVerifyClient != SSL_CVERIFY_UNSET) ||
 (sc->server->auth.verify_mode != SSL_CVERIFY_UNSET)) {
 
 /* remember old state */
-verify_old = SSL_get_verify_mode(ssl);
+verify_old = verify;
 /* configure new state */
 verify = SSL_VERIFY_NONE;
 
@@ -703,12 +704,6 @@ int ssl_hook_Access(request_rec *r)
 verify |= SSL_VERIFY_PEER;
 }
 
-/* TODO: this seems premature since we do not know if there
- *   are any changes required.
- */
-SSL_set_verify(ssl, verify, ssl_callback_SSLVerify);
-SSL_set_verify_result(ssl, X509_V_OK);
-
 /* determine whether we've to force a renegotiation */
 if (!renegotiate && verify != verify_old) {
 if (((verify_old == SSL_VERIFY_NONE) &&
@@ -727,7 +722,6 @@ int ssl_hook_Access(request_rec *r)
  * on this connection.
  */
 apr_table_setn(r->notes, "ssl-renegotiate-forbidden", "verify-client");
-SSL_set_verify(ssl, verify_old, ssl_callback_SSLVerify);
 return HTTP_FORBIDDEN;
 }
 /* optimization */
@@ -802,7 +796,6 @@ int ssl_hook_Access(request_rec *r)
  "'require' and VirtualHost-specific CA certificate "
  "list is only available to clients with TLS server "
  "name indication (SNI) support");
-SSL_set_verify(ssl, verify_old, NULL);
 return HTTP_FORBIDDEN;
 } else
 /* let it pass, possibly with an "incorrect" peer cert,
@@ -850,6 +843,7 @@ int ssl_hook_Access(request_rec *r)
 ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(02257)
   "could not buffer message body to allow "
   "SSL renegotiation to proceed");
+r->connection->keepalive = AP_CONN_CLOSE;
 return rv;
 }
 }
@@ -872,6 +866,9 @@ int ssl_hook_Access(request_rec *r)
 ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, APLOGNO(02221)
   "Requesting connection re-negotiation");
 
+SSL_set_verify(ssl, verify, NULL);
+SSL_set_verify_result(ssl, X509_V_OK);
+
 if (renegotiate_quick) {
 STACK_OF(X509) *cert_stack;
 
@@ -898,6 +895,7 @@ int ssl_hook_Access(request_rec *r)
 ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(0)
   "Cannot find peer certificate chain");
 
+r->connection->keepalive = AP_CONN_CLOSE;
 return HTTP_FORBIDDEN;
 }
 
@@ -907,6 +905,7 @@ int ssl_hook_Access(request_rec *r)
 ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(02223)
   "Cannot find certificate storage");
 
+r->connection->keepalive = AP_CONN_CLOSE;
 return HTTP_FORBIDDEN;
 }
 
@@ -2462,7 +2461,7 @@ int ssl_callback_SRPServerParams(SSL *ssl, int *ad
 #if OPENSSL_VERSION_NUMBER >= 0x1010L
 SRP_user_pwd_free(u);
 #endif
-SSL_set_verify(ssl, SSL_VERIFY_NONE,  ssl_callback_SSLVerify);
+SSL_set_verify(ssl, SSL_VERIFY_NONE, NULL);
 return SSL_ERROR_NONE;
 }
 

Re: svn commit: r1750779 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_kernel.c

[Stefan Eissing]

We now set exactly the same callback right before in line 709. If we had more 
than one callback, we would not have to specify NULL, but restore any previous 
callback there was, right?

But that is all just theoretical, as You and Yann already stated.

> Am 30.06.2016 um 17:26 schrieb Yann Ylavic :
> 
> On Thu, Jun 30, 2016 at 5:05 PM, Ruediger Pluem  wrote:
>> 
>> Is there a reson why we use ssl_callback_SSLVerify instead of NULL like we 
>> do in asimilar situation below?
>> IMHO we do not want to change the callback here to whatever it may set.
>> I agree that in practice there won't be any difference right now, since we 
>> only have one callback.
> 
> I agree that if/when we have multiple callback possibilities, we
> should set NULL here, but also above where we force the new mode.
> 
> Nothing to worry about for now, though.
> 
> Regards,
> Yann.

Re: svn commit: r1750779 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_kernel.c

[Yann Ylavic]

On Thu, Jun 30, 2016 at 5:05 PM, Ruediger Pluem  wrote:
>
> Is there a reson why we use ssl_callback_SSLVerify instead of NULL like we do 
> in asimilar situation below?
> IMHO we do not want to change the callback here to whatever it may set.
> I agree that in practice there won't be any difference right now, since we 
> only have one callback.

I agree that if/when we have multiple callback possibilities, we
should set NULL here, but also above where we force the new mode.

Nothing to worry about for now, though.

Regards,
Yann.

Re: svn commit: r1750779 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_kernel.c

[Ruediger Pluem]

On 06/30/2016 02:08 PM, ic...@apache.org wrote:
> Author: icing
> Date: Thu Jun 30 12:08:42 2016
> New Revision: 1750779
> 
> URL: http://svn.apache.org/viewvc?rev=1750779=rev
> Log:
> modssl: reset client-verify state when renegotiation is aborted
> 
> Modified:
> httpd/httpd/trunk/CHANGES
> httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
> 
> Modified: httpd/httpd/trunk/CHANGES
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1750779=1750778=1750779=diff
> ==
> --- httpd/httpd/trunk/CHANGES [utf-8] (original)
> +++ httpd/httpd/trunk/CHANGES [utf-8] Thu Jun 30 12:08:42 2016
> @@ -1,6 +1,9 @@
>   -*- coding: utf-8 
> -*-
>  Changes with Apache 2.5.0
>  
> +  *) mod_ssl: reset client-verify state of ssl when aborting renegotiations.
> + [Erki Aring , Stefan Eissing]
> +
>*) mod_proxy_{http,ajp,fcgi}: don't reuse backend connections with data
>   available before the request is sent.  PR 57832.  [Yann Ylavic]
>  
> 
> Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c?rev=1750779=1750778=1750779=diff
> ==
> --- httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c (original)
> +++ httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c Thu Jun 30 12:08:42 2016
> @@ -727,6 +727,7 @@ int ssl_hook_Access(request_rec *r)
>   * on this connection.
>   */
>  apr_table_setn(r->notes, "ssl-renegotiate-forbidden", 
> "verify-client");
> +SSL_set_verify(ssl, verify_old, ssl_callback_SSLVerify);

Is there a reson why we use ssl_callback_SSLVerify instead of NULL like we do 
in asimilar situation below?
IMHO we do not want to change the callback here to whatever it may set.
I agree that in practice there won't be any difference right now, since we only 
have one callback.

Regards

Rüdiger

Re: Mergine of Multiple Cookie Headers

[Yann Ylavic]

On Thu, Jun 30, 2016 at 4:46 PM, Rainer Canavan
 wrote:
> On Wed, Jun 29, 2016 at 10:27 AM, Yann Ylavic  wrote:
>>
>> RequestHeader edit* Cookie
>> ([^=;,]++)(="(?:[^"].)*+[^"]*+"|[^;,]*)?+[;,] $1$2; early
>
> I have to admit that I'd never have thought of using mod_headers. Both
> solutions work as expected, but Yann's solution looks somewhat more
> robust to me, so I think I'll go with that.

I think I forgot a .*+ above to really eat the quoted escapes, so I'd
rather propose:
RequestHeader edit* Cookie
([^=;,]++)(="(?:[^"]*+.)*+[^"]*+"|[^;,]*)?+[;,] $1$2; early

Regards,
Yann.

Re: Last-Modified header value returned by FCGI scripts

[Luca Toscano]

2016-06-29 16:31 GMT+02:00 Luca Toscano :

>
>
> 2016-06-29 14:06 GMT+02:00 William A Rowe Jr :
>
>> On Wed, Jun 29, 2016 at 3:12 AM, Luca Toscano 
>> wrote:
>>
>>> Hi Apache devs!
>>>
>>> I have been working on an email thread [1] in the users@ mailing list
>>> in which it was asked some questions about how httpd (using mod-proxy-fcgi)
>>> manages Last-Modified headers returned by FCGI/CGI scripts. Two strange
>>> behaviors were brought up:
>>>
>>> 1) Last-Modified: foo returned by a simple PHP script forces httpd to
>>> replace it with Thu, 01 Jan 1970 00:00:00 GMT. Patch proposed to backport:
>>> http://svn.apache.org/r1748379
>>>
>>
>> Sensible, but we should be filling this in with now(), based on comments
>> in 14.29?
>>
>
> Very open to discuss this one, I have some doubts too. I chose to drop the
> header since I applied 14.29 only to dates (i.e. not triggering any
> APR_DATE_BAD after parsing) and not to completely wrong values like "foo".
> My aim was to drop any non parsable date (logging the action) and to
> correct the rest if considered in the future from httpd's point of view.
>
>
>>
>>
>>> 2) Last-Modified header value with a date not in GMT are replaced with
>>> (now() + time taken to serve the request) without any trace in the logs.
>>> This seems to be due to httpd recognizing the date as "in the future" and
>>> replacing it with its response origination time (following
>>> https://tools.ietf.org/html/rfc2616#section-14.29).
>>>
>>
>> https://tools.ietf.org/html/rfc2616#section-3.3.1 declares these are
>> meaningless, and we follow the appropriate recommendations.
>>
>
> +1, completely missed this part: "This is indicated in the first two
> formats by the inclusion of "GMT" as the three-letter abbreviation for time
> zone, and MUST be assumed when reading the asctime format."
>
>
>>
>>
>>> To demonstrate 2), Manuel in users@ suggested a simple PHP script
>>> returning the current datetime in the Europe/Paris timezone (GMT +2). I
>>> tried to check the code and I came up with two possible solutions:
>>>
>>> 1)  mod-proxy-fcgi eventually triggers a call
>>> to ap_scan_script_header_err_core_ex in util_script.c that
>>> uses apr_date_parse_http to transform a datestring into a unix timestamp.
>>> This one seems not to check the timezone, assuming GMT all the times. It
>>> might be an option to add a check in the code to return APR_DATE_BAD in
>>> case the datetime is not GMT, and then r1748379 will take care of the rest.
>>> This could potentially break existing code that relies on this behavior to
>>> work correctly.
>>>
>>
>> -0 on recognizing non-GMT, per section 3.3.1 of spec.
>>
>
> Yes completely agree.
>
>
>>
>>
>>> 2) Simply log what httpd does, for example with http://apaste.info/8pa
>>> or http://apaste.info/JlZ (wording might need to be changed).
>>>
>>
>> +1 in all cases to adding trace messages for sysadmins debugging bad cgi.
>>
>>
Added logging in http://svn.apache.org/r1750747 and
http://svn.apache.org/r1750749 (last one is to fix indentation issues, my
bad).

It would be good to get other comments for http://svn.apache.org/r1748379,
to follow up on what William suggested in his previous email.

Thanks!

Regards,

Luca

Re: Mergine of Multiple Cookie Headers

[Rainer Canavan]

On Wed, Jun 29, 2016 at 10:27 AM, Yann Ylavic  wrote:
> On Wed, Jun 29, 2016 at 9:33 AM, Plüm, Rüdiger, Vodafone Group
>  wrote:
[..]
>>> We've observed multiple gateways, operated by e.g. AT, COLT and
>>> Vodafone, that inject additional Cookie: headers into client requests,
>>> such as
>>>
>>> Cookie: actually=from_the_client
>>> Cookie: Bearer-Type=w-TCP
>>> Cookie: network-access-type=UMTS

>> How about
>>
>> RequestHeader edit* Cookie ", " "; "
>
> Or possibly something more generic (quoting, escaping...), but less readable 
> :p
>
> RequestHeader edit* Cookie
> ([^=;,]++)(="(?:[^"].)*+[^"]*+"|[^;,]*)?+[;,] $1$2; early
>
> (with or without the "early" flag)
>
> Regards,
> Yann.

I have to admit that I'd never have thought of using mod_headers. Both
solutions work as expected, but Yann's solution looks somewhat more
robust to me, so I think I'll go with that.

thanks,

rainer

Re: 2.4.23 T Status

[Jim Jagielski]

I will doing a T of 2.4.23 this (Thurs) afternoon (eastern)...

Re: svn commit: r1750771 - /httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy_http2.html.en

[Stefan Eissing]

Thanks, Jim!

> Am 30.06.2016 um 13:14 schrieb j...@apache.org:
> 
> Author: jim
> Date: Thu Jun 30 11:14:31 2016
> New Revision: 1750771
> 
> URL: http://svn.apache.org/viewvc?rev=1750771=rev
> Log:
> xforms
> 
> Modified:
>httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy_http2.html.en
> 
> Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy_http2.html.en
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy_http2.html.en?rev=1750771=1750770=1750771=diff
> ==
> --- httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy_http2.html.en 
> (original)
> +++ httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy_http2.html.en Thu 
> Jun 30 11:14:31 2016
> @@ -45,7 +45,7 @@
> have to be present in the server.
> 
>  href="../mod/mod_proxy_http2.html">mod_proxy_http2 works with 
> incoming requests
> -over HTTP/1.1 and HTTP/2 requests. If  href="../mod/mod_proxy_http2.html">mod_proxy_http2
> +over HTTP/1.1 and HTTP/2 requests. If  href="../mod/mod_http2.html">mod_http2
> handles the frontend connection, requests against the same HTTP/2
> backend are sent over a single connection, whenever possible.
> 
> 
> 

Re: [PATCH] on TRACE & RFC compliance

[Joe Orton]

Thanks a lot, all.  I dropped the last sentence and pushed to trunk & 
2.4.x.   r1750750 & r1750752