Re: svn commit: r1188950 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/httpd.h include/util_varbuf.h modules/filters/mod_substitute.c server/util.c
On Oct 26, 2011, at 3:46 PM, Stefan Fritsch wrote:
On Wednesday 26 October 2011, Jim Jagielski wrote:
On Oct 25, 2011, at 6:29 PM, s...@apache.org wrote:
+if (len maxlen maxlen 0)
+return APR_ENOMEM;
+
if (!vb) {
-dest = dst = apr_pcalloc(p, len + 1);
+*result = dst = apr_pcalloc(p, len + 1);
if len == maxlen and == APR_SIZE_MAX then doesn't
the len+1 blow us up?
APR_SIZE_MAX means no limit, i.e. it will blow up when there is no
memory left, which will be well before APR_SIZE_MAX. I guess I should
have used 0, that would have been clearer.
I thought that
#define APR_SIZE_MAX(~((apr_size_t)0))
returned the one's complement of 0, which would basically
be the largest value possible for (apr_size_t)0, and that
adding 1 to it would overflow… right? Or am I still jet-lagged
(which is quite possible).
The main question is whether or not maxlen accounts for
the NUL or not; we seem inconsistent in that regard with
this patch.
2.0.65 and 2.3.15-dev
Still hoping to get these out, esp getting the ball rolling for an actual 2.4.0 GA by ApacheCon… There is a hold up due to an issue which may need to be fixed/addressed and that's the reason for the delay...
Re: 2.0.65 and 2.3.15-dev
On Oct 27, 2011, at 10:31 AM, Jim Jagielski wrote: Still hoping to get these out, esp getting the ball rolling for an actual 2.4.0 GA by ApacheCon… There is a hold up due to an issue which may need to be fixed/addressed and that's the reason for the delay... Thanks Jim, I was just considering asking about this. Is anyone on the list actually running the previous beta in anger? Aside from www.apache.org? S. -- scte...@apache.orghttp://www.temme.net/sander/ PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A View my availability: http://tungle.me/sctemme
Re: 2.0.65 and 2.3.15-dev
On Oct 27, 2011, at 1:33 PM, Sander Temme wrote: On Oct 27, 2011, at 10:31 AM, Jim Jagielski wrote: Still hoping to get these out, esp getting the ball rolling for an actual 2.4.0 GA by ApacheCon… There is a hold up due to an issue which may need to be fixed/addressed and that's the reason for the delay... Thanks Jim, I was just considering asking about this. Is anyone on the list actually running the previous beta in anger? Aside from www.apache.org? Some parts of some Red Hat projects are...
Re: svn commit: r1188950 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/httpd.h include/util_varbuf.h modules/filters/mod_substitute.c server/util.c
On Thursday 27 October 2011, Jim Jagielski wrote:
On Oct 26, 2011, at 3:46 PM, Stefan Fritsch wrote:
On Wednesday 26 October 2011, Jim Jagielski wrote:
On Oct 25, 2011, at 6:29 PM, s...@apache.org wrote:
+if (len maxlen maxlen 0)
+return APR_ENOMEM;
+
if (!vb) {
-dest = dst = apr_pcalloc(p, len + 1);
+*result = dst = apr_pcalloc(p, len + 1);
if len == maxlen and == APR_SIZE_MAX then doesn't
the len+1 blow us up?
APR_SIZE_MAX means no limit, i.e. it will blow up when there is
no memory left, which will be well before APR_SIZE_MAX. I guess
I should have used 0, that would have been clearer.
I thought that
#define APR_SIZE_MAX(~((apr_size_t)0))
returned the one's complement of 0, which would basically
be the largest value possible for (apr_size_t)0, and that
adding 1 to it would overflow… right? Or am I still jet-lagged
(which is quite possible).
That's correct, it would crash if len == APR_SIZE_MAX. But my point
was that it would also crash for len == APR_SIZE_MAX-1000, because by
definition, the machine cannot have that much free mem and apr_pcalloc
would call abort(). So in both cases, the amount of free memory is the
limit. But aborting with out-of-mem is more correct than simply
segfaulting, therefore I have fixed it.
The main question is whether or not maxlen accounts for
the NUL or not; we seem inconsistent in that regard with
this patch.
True. I think this is also fixed with r1189985.
Re: RFE: Control of HTTP cache control headers within mod_rewrite rules
On Tuesday 25 October 2011, Noah Robin wrote:
I ran some tests on this and the following modified version will
work:
Header always set Cache-Control max-age=%{CACHE_LIFETIME}e
env=CACHE_LIFETIME
RewriteRule /example http://www.example.com/
[E=CACHE_LIFETIME:604800]
..however, this still leaves an open question in my mind: How to
solve for the more general case where I want Apache to set the
cache control header on any 301 it sends, even if the 301 was
generated within the application rather than in Apache's
configuration. I don't see a way to set an environment variable
based on a response attribute (e.g. r-status). Am I missing
something or would something need to be written to handle this
case?
2.3/2.4 supports this:
Header set Cache-Control max-age=604800 %{REQUEST_STATUS} == 301
or even %{REQUEST_STATUS} -in { 301 , 302 }. This is a good
candidate for an example in the docs.
I can't think of a way to do this in 2.2.x, though.
Re: RFE: Control of HTTP cache control headers within mod_rewrite rules
On Oct 27, 2011, at 3:35 PM, Stefan Fritsch wrote:
On Tuesday 25 October 2011, Noah Robin wrote:
I ran some tests on this and the following modified version will
work:
Header always set Cache-Control max-age=%{CACHE_LIFETIME}e
env=CACHE_LIFETIME
RewriteRule /example http://www.example.com/
[E=CACHE_LIFETIME:604800]
..however, this still leaves an open question in my mind: How to
solve for the more general case where I want Apache to set the
cache control header on any 301 it sends, even if the 301 was
generated within the application rather than in Apache's
configuration. I don't see a way to set an environment variable
based on a response attribute (e.g. r-status). Am I missing
something or would something need to be written to handle this
case?
2.3/2.4 supports this:
Header set Cache-Control max-age=604800 %{REQUEST_STATUS} == 301
or even %{REQUEST_STATUS} -in { 301 , 302 }. This is a good
candidate for an example in the docs.
I can't think of a way to do this in 2.2.x, though.
In 2.2 you can do this with mod_setenvifplus
http://modsetenvifplus.sourceforge.net/. I do things like this all of the
time.
