Re: RedirectMatch: unexpected behavior within
On Wed, May 17, 2017 at 9:12 AM, Reindl Harald wrote:
>
>
> RedirectMatch 404 "(?i)\/[\.]{0,1}(cvs|svn)\/"
>
>
>
> that above don't work and don't warn as it is normally the case where a
> "apachectl -t" clearly says "syntax error, xxx not allowed here"
>
> don't work means RedirectMatch also applies to GET-requests which makes it
> really hard to restrict extensions like below only for normal webacess which
> is chained into "AllowMethods GET HEAD POST" but at the same time allow time
> for mod_dav_svn methods
>
> well, and there is also no option to remove one or all global set
> "RedirectMatch" for a specific directory
>
> RedirectMatch 404
> "(?i)\.(asax|ascx|ashx|asmx|asp|aspx|axd|back|backup|bak|bat|cfm|class|class\.php|cmd|conf|config|csproj|dat|data|db[0-9]{0,1}|dll|ds_store|exe|fbcindex|idc|inc|ini|jhtml|jsp|jspa|key|log|mdb|mdf|mscgi|nasl|nsf|ocx|old|pl|py|rb|sample|sav|save|sh|shtm|sql|sqlite|vbproj|vbs|webinfo)$"
These containers should be marked deprecated in 2.4 and riddled with
cautions that they only apply to access control.
Re: the non dev@ related stuff, use .
--
Eric Covener
cove...@gmail.com
RedirectMatch: unexpected behavior within
RedirectMatch 404 "(?i)\/[\.]{0,1}(cvs|svn)\/"
that above don't work and don't warn as it is normally the case where a
"apachectl -t" clearly says "syntax error, xxx not allowed here"
don't work means RedirectMatch also applies to GET-requests which makes
it really hard to restrict extensions like below only for normal
webacess which is chained into "AllowMethods GET HEAD POST" but at the
same time allow time for mod_dav_svn methods
well, and there is also no option to remove one or all global set
"RedirectMatch" for a specific directory
RedirectMatch 404
"(?i)\.(asax|ascx|ashx|asmx|asp|aspx|axd|back|backup|bak|bat|cfm|class|class\.php|cmd|conf|config|csproj|dat|data|db[0-9]{0,1}|dll|ds_store|exe|fbcindex|idc|inc|ini|jhtml|jsp|jspa|key|log|mdb|mdf|mscgi|nasl|nsf|ocx|old|pl|py|rb|sample|sav|save|sh|shtm|sql|sqlite|vbproj|vbs|webinfo)$"
Re: drop experimental from http2 for 2.4.next?
I was talking about the way ahead for HTTP/2 support in httpd. Regarding it as no longer "experimental" helps, I hope, to make better progress on this. There have been two aspects to "experimental" in my mind: 1. The "we do not guarantee that this is how it will stay". Anything may change in the next release to make it better and better. 2. We try this out. It's an experiment. It may go away again. Removing "experimental" makes it clear to everyone that the project has been working on 1 and that http2 has become a core part of httpd, similar to ssl. And as more than one person is working on ssl, I hope that we will have more people working on http2. -Stefan > Am 16.05.2017 um 20:50 schrieb Eric Covener : > > On Mon, Apr 17, 2017 at 4:24 AM, Stefan Eissing > wrote: >> What needs to be done? From what I saw in the last two years, these >> are key areas to improve: >> >> 1. separation of semantics and serialisation >> 2. connections with >1 requests simultaneously >> >> mod_http need to spin off a mod_http1 with the parts that read >> and write headers, handle chunked encoding in requests >> and responses. etc. >> >> mpm needs facilities for processing slave connections and assign >> its resources to slave/master connections in fair and performant >> ways. >> >> As much as I like to work on it, I am certainly not able to do >> that by myself. So, yes, I welcome getting rid of experimental. > > > I'm sorry, but can you clarify the relationship between the initial > bit and the welcoming of it not experimental? > > -- > Eric Covener > cove...@gmail.com
