OK I tried to find a more robust alternative but could not. I was thinking
I could duplicate whatever mod_rewrite was doing to set the request filename
that appears to be complex and probably no less brittle.
I have another query on this. In reality we do *not* want our rewritten
resources to
I have implemented Ben's hack in mod_pagespeed in
http://code.google.com/p/modpagespeed/source/detail?r=345 . It works great.
But I am concerned that a subtle change to mod_rewrite.c will break this
hack silently. We would catch it in our regression tests, but the large
number of Apache users
On Mon, Jan 3, 2011 at 4:50 PM, Ben Noordhuis i...@bnoordhuis.nl wrote:
This means that returning OK from my handler does not prevent
mod_authz_host's handler from being called.
You're mistaken, Joshua. The access_checker hook by default is empty.
mod_authz_host is a module and it can be
The access checking on mod_pagespeed resources is
redundant, because the resource will either be served from cache (in which
case it had to be authenticated to get into the cache in the first place) or
will be decoded and the original resource(s) fetched from the same server
with full
On Mon, Jan 3, 2011 at 6:15 PM, Eric Covener cove...@gmail.com wrote:
The access checking on mod_pagespeed resources is
redundant, because the resource will either be served from cache (in
which
case it had to be authenticated to get into the cache in the first
place) or
will be decoded
On Mon, Jan 3, 2011 at 23:19, Joshua Marantz jmara...@google.com wrote:
My goal is not to remove authentication from the server; only from messing
with my module's rewritten resource. The above statement is just observing
that, while it's possible to shunt off mod_rewrite by returning OK from
On 02.01.2011 01:04, Stefan Fritsch wrote:
This will still treat non character string types (such as OCTET
STRING) incorrectly, but I think we can ignore that problem. Or do you
think we should add ASN1_STRFLGS_DUMP_UNKNOWN | ASN1_STRFLGS_DUMP_DER,
too?
I wouldn't recommend to add these,
On 02.01.2011 19:35, Stefan Fritsch wrote:
On Sunday 02 January 2011, Rüdiger Plüm wrote:
Modified: httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_u
til_ssl.c?rev=1054323r1=1054322r2=1054323view=diff
on EBCDIC platforms, ap_xlate_proto_from_ascii simply does nothing (it
calls apr_xlate_conv_buffer, which returns APR_ENOTIMPL, even in current
versions of APR-util, IIMN).
For EBCDIC you're being mislead by the !APR_HAS_XLATE half of xlate.c
-- it's not a no-op.
On Mon, Jan 3, 2011 at 1:21 PM, Eric Covener cove...@gmail.com wrote:
on EBCDIC platforms, ap_xlate_proto_from_ascii simply does nothing (it
calls apr_xlate_conv_buffer, which returns APR_ENOTIMPL, even in current
versions of APR-util, IIMN).
For EBCDIC you're being mislead by the
On 03.01.2011 19:21, Eric Covener wrote:
on EBCDIC platforms, ap_xlate_proto_from_ascii simply does nothing (it
calls apr_xlate_conv_buffer, which returns APR_ENOTIMPL, even in current
versions of APR-util, IIMN).
For EBCDIC you're being mislead by the !APR_HAS_XLATE half of xlate.c
-- it's
On Mon, Jan 3, 2011 at 1:47 PM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
On 03.01.2011 19:21, Eric Covener wrote:
on EBCDIC platforms, ap_xlate_proto_from_ascii simply does nothing (it
calls apr_xlate_conv_buffer, which returns APR_ENOTIMPL, even in current
versions of APR-util, IIMN).
On Sunday 02 January 2011, Dr Stephen Henson wrote:
On 02/01/2011 18:42, Stefan Fritsch wrote:
On Sunday 02 January 2011, Dr Stephen Henson wrote:
There is a bug in OpenSSL currently for those options: it
doesn't escape the escape character itself (which it should
treat as a special case
I answered my own question by implementing it and failing. You can't bypass
mod_authz_host because it gets invoked via the magic macro:
AP_IMPLEMENT_HOOK_RUN_ALL(int,access_checker,
(request_rec *r), (r), OK, DECLINED)
This means that returning OK from my handler
On Monday 03 January 2011, Kaspar Brand wrote:
On 03.01.2011 19:21, Eric Covener wrote:
on EBCDIC platforms, ap_xlate_proto_from_ascii simply does
nothing (it calls apr_xlate_conv_buffer, which returns
APR_ENOTIMPL, even in current versions of APR-util, IIMN).
For EBCDIC you're being
On 1/3/2011 3:06 PM, Stefan Fritsch wrote:
The single octet 0xFF should be converted to some UTF8 character
according to the string type it occurs in, shouldn't it? Since we are
only escaping control characters I expect that only the codes in the
range \00 to \1F can appear in \xx form.
On Mon, Jan 3, 2011 at 22:07, Joshua Marantz jmara...@google.com wrote:
I answered my own question by implementing it and failing. You can't bypass
mod_authz_host because it gets invoked via the magic macro:
AP_IMPLEMENT_HOOK_RUN_ALL(int,access_checker,
(request_rec
On 03.01.2011 22:06, Stefan Fritsch wrote:
On Sunday 02 January 2011, Dr Stephen Henson wrote:
I'm thinking here how that might be abused. In the current broken
OpenSSL code it doesn't escape a backslash with those options. So
the following look identical when printed:
1. The single octet
On 03.01.2011 22:11, Stefan Fritsch wrote:
On Monday 03 January 2011, Kaspar Brand wrote:
Ah, right - my mistake. But even on an EBCDIC platform,
ap_xlate_proto_from_ascii would only make sense if we were
converting pure 8-bit character strings (from ISO-8859-1 to some
EBCDC code page),
19 matches
Mail list logo
