Re: [users@httpd] Re: apache service interruption

2013-08-02 Thread Michael D. Wood
You could potentially deny legitimate users access.  I limit so many 
connections per second per source IP.  If I knew I were getting a ton of 
traffic from a University I would have to adjust it accordingly.


The setting in pfsense is Maximum new connections / per second(s) - 
that's per IP.  My site I wouldn't say is pegged with University traffic 
sharing the same IP.  I'm just giving you examples and tailor to your 
needs.  If you get a bunch of traffic from a shared IP, obviously, this 
would not be the best way to go.  I try to mitigate using rate limiting.


I don't like to wait for the traffic to pass to Apache and have to 
configure a module to fix it.  Apache should be handling web requests, 
not having to deal with tons of traffic (bruteforce/DoS).  I try to 
handle that stuff before it even gets passed to Apache.


From the Cisco side you could implement ACL's and rate limiting.

http://www.debian-administration.org/articles/187

On 08/02/2013 01:49 AM, Grant wrote:

Truthfully, I've always limited connections from the source IP via a
firewall before the traffic is even passed to apache.


Do you do this only when under DoS attack or all the time?

Won't you potentially prevent legitimate users from making a single
connection if they're connecting with a shared IP from a university
campus (for example)?

How is this accomplished with iptables?

- Grant


Two different things come to mind.  Kingcope found an Apache 
byterange
vulnerability and the PoC code he wrote for it exhausts the 
resources on

a
server running Apache.  Only 1 instance of his perl script had to 
be ran.
LOIC is another that could possible DoS your server from one 
source. What

IP address was hitting your box when this happened?



I'd rather not post the IP if that's OK.  I did notice my 
access_log

entries were out of chronological order for the IP address in
question.  Does that indicate a Slowloris attack?  Maybe it's just 
the
result of the server bogging down in response to so many requests 
in a

short amount of time.

So I'm sure I understand, a regular browser or unsophisticated 
script
shouldn't be able to interrupt apache service by simply requesting 
a

large number of pages in a short amount of time?  If not, how does
apache prevent that from happening?

- Grant


You wouldn't keep a syn proxy rule enabled all the time; only 
under a

DoS
attack.  You could also implement ModSecurity.




ModSecurity looks good and I think it works with nginx as well as
apache.  Is everyone who isn't running OSSEC HIDS or ModSecurity
vulnerable to a single client requesting too many pages and
interrupting the service?

- Grant


Also, you should be able to limit simultaneous client 
connections

with
your
firewall and pass the traffic in a syn proxy state. There are
numerous
ways
to achieve this.





Is that the best way to go besides OSSEC HIDS?  I can imagine 
that

sort of thing could cause problems.

- Grant



You can always compile from source ;)
What version of Apache are you running?

On 07/29/2013 02:59 AM, Grant wrote:





Was it just an IP exhausting the apache service with too 
many
connections?  What do you see in the access logs?  I use 
OSSEC

HIDS
on
my
apache servers to mitigate this.






In the access log I see the same IP made many requests 
during the
service interruption and I think that exhausted the apache 
service.
It looks like there isn't a Gentoo ebuild for OSSEC HIDS.  
Is there

another way to prevent this sort of thing?

- Grant


My server has 4GB RAM and uses nginx as a reverse proxy 
to

apache.
A
little while ago my website became inaccessible for about 
30

minutes.
I checked my munin graphs and it looks like apache 
processes

spiked
to
about 29 during this time which is many times greater 
than

usual.
I
have MaxClients at 30 and the error log verifies that 
MaxClients

was
not reached.  The strange part is system disk latency 
shows a

spike
during the interruption which is only very slightly 
greater than

other
spikes which did not interrupt service.  System CPU, 
memory, and

swap
usage don't show anything interesting at all.

Does this make sense to anyone?  Should I decrease 
MaxClients?


- Grant






I've looked over my access_log and I can see there is a
particular
IP
which was making many requests during the interruption.  
Since

munin
does not show there was an excessive amount of memory or 
CPU

usage,
lowering MaxClients won't help?

- Grant


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



Re: [users@httpd] Re: apache service interruption

2013-08-02 Thread Pete Houston
On Thu, Aug 01, 2013 at 10:49:59PM -0700, Grant wrote:
 Do you do this only when under DoS attack or all the time?

All the time.

 Won't you potentially prevent legitimate users from making a single
 connection if they're connecting with a shared IP from a university
 campus (for example)?

Yes. However, if you don't do it you potentially prevent legitimate
users from anywhere from making a connection because some greedy user is
using up all your server's resources.

 How is this accomplished with iptables?

With connlimit and/or one of the rate-limiting modules.

Just to bring it back on topic, the disadvantage of implementing this at
the firewall is that it is very broad-brush (unless you use DPI). You
will be limiting connections regardless of the target vhost or path or
MIME type or whatever. By doing it in apache with mod_limitipconn or
similar you can easily apply stricter limits to heavier content, for
example.

So, IMHO the best plan is to put an absolute limit in the firewall for
the worst possible scenario but then tailor the individual limits for
vhosts and content types etc. within apache.

Pete
-- 
Openstrike - improving business through open source
http://www.openstrike.co.uk/ or call 01722 770036 / 07092 020107


pgp0GpUkERS5h.pgp
Description: PGP signature


[users@httpd] upgrade to apache 2.4.4 and peformance issue

2013-08-02 Thread S R
I upgraded from Apache 2.0.63 to 2.4.4 and changed the pages from using jsp 
with modcaucho and resin to using modphp 5.4.16. I have seen a significant 
reduction in page response times.  Does anyone have any suggestions on what 
would cause this?

Re: [users@httpd] upgrade to apache 2.4.4 and peformance issue

2013-08-02 Thread Tom Evans
On Fri, Aug 2, 2013 at 10:15 AM, S R sr78912...@yahoo.com wrote:
 I upgraded from Apache 2.0.63 to 2.4.4 and changed the pages from using jsp
 with modcaucho and resin to using modphp 5.4.16. I have seen a significant
 reduction in page response times.  Does anyone have any suggestions on what
 would cause this?

I would doubt very much this has anything to do with Apache - you've
changed a lot more than Apache there.

You could verify the problem is in your new web application by
deploying it under 2.0 and comparing with 2.4.

Cheers

Tom

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



[users@httpd] Rewrite Rule

2013-08-02 Thread Mukesh Kumar
Hi,

I have below similar rewrite rule in my conf - 
---
RewriteCond %{HTTP_HOST} 
^abc.xyz.com|^abc$
RewriteCond %{REQUEST_URI} !^/abc/.*
RewriteRule 
^(.*)$ http://xyz.com/test/ 
 [E=HTTP_REFERER:%{HTTP_REFERER},L]
---

If i hit, abc.xyz.com or abc - it redirects as per rule to 
http://xyz.com/test/Also, If i hit /abc/dummy - it still redirects to 
http://xyz.com/test/ , even though 2nd line of rule starts with !(not).

can someone help me understand the rule?

Tnx,
Mukesh



  

[users@httpd] Setting up Apache Subversion

2013-08-02 Thread Scott Genevish
I'm getting an error when I try to checkout a subversion repository, Redirect 
cycle detected for URL 'http://10.224.48.53:8080/svn/main'.  This seems to be 
a misconfiguration in Apache, which is why I came here, but please correct me 
if I'm wrong.

The key sections of the subversion.conf are:

###
# Work around authz and SVNListParentPath issue
RedirectMatch ^(/svn)$ $1/

Location /svn/
DAV svn
SVNParentPath /var/www/html/svn
#SVNPath /var/www/html/svn/main
#List repositories collection
SVNListParentPath on
SVNPathAuthz off
#Enable WebDAV automatic versioning
SVNAutoversioning on
#Repository Display Name
SVNReposName MiMedx SVN Repositories
/Location
##

The access_log shows:

##
10.224.129.178 - - [02/Aug/2013:15:32:11 -0400] OPTIONS /svn/main HTTP/1.1 
401 482 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
10.224.129.178 - sgenevish [02/Aug/2013:15:32:11 -0400] OPTIONS /svn/main 
HTTP/1.1 301 323 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
10.224.129.178 - - [02/Aug/2013:15:32:11 -0400] OPTIONS /svn/main HTTP/1.1 
401 482 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
10.224.129.178 - sgenevish [02/Aug/2013:15:32:11 -0400] OPTIONS /svn/main 
HTTP/1.1 301 323 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
10.224.129.178 - - [02/Aug/2013:15:32:12 -0400] OPTIONS /svn/main HTTP/1.1 
401 482 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
10.224.129.178 - sgenevish [02/Aug/2013:15:32:12 -0400] OPTIONS /svn/main 
HTTP/1.1 301 323 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
10.224.129.178 - - [02/Aug/2013:15:32:12 -0400] OPTIONS /svn/main HTTP/1.1 
401 482 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
10.224.129.178 - sgenevish [02/Aug/2013:15:32:12 -0400] OPTIONS /svn/main 
HTTP/1.1 301 323 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
##

I don't think there's anything particularly relevant in httpd.conf, except 
maybe:

##
ServerRoot /etc/httpd
Listen 8080
DocumentRoot /var/www/html
##

There are no symbolic links in the directory.

Thanks,

-Scott
This email message and any attachments are for the sole use of the above-named 
intended recipient(s). This email and any attachments are confidential and 
proprietary to MiMedx Group, Inc. and may also contain certain privileged 
attorney-client information. This information is intended only for the use of 
the individual entity or intended recipient addressed above. You are not to 
use, disclose, distribute or disseminate this email by any means without the 
expressed permission of MiMedx Group, Inc. If you are not the intended 
recipient, or the employee or agent responsible for delivering  this email to 
the intended recipient, you are hereby notified that any use, disclosure, 
printing, copying, distribution or dissemination by any means of this email or 
any attachments is strictly prohibited. If you have received this email in 
error, please immediately notify the sender by telephone at (678) 384-6720 or 
by reply email and delete this email and any attachments and destroy all hard 
copies. Thank you.




-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



Re: [users@httpd] Setting up Apache Subversion

2013-08-02 Thread Macks, Aaron
Slash versus no slash.  You're redirecting things that aren't /svn to /svn/ 
(note the trailing slash). I think if you remove the $ from the regex it should 
work 
A

On Aug 2, 2013, at 4:28 PM, Scott Genevish sgenev...@mimedx.com wrote:

 I'm getting an error when I try to checkout a subversion repository, 
 Redirect cycle detected for URL 'http://10.224.48.53:8080/svn/main'.  This 
 seems to be a misconfiguration in Apache, which is why I came here, but 
 please correct me if I'm wrong.  
 
 The key sections of the subversion.conf are:
 
 ###
 # Work around authz and SVNListParentPath issue
 RedirectMatch ^(/svn)$ $1/
 
 Location /svn/
DAV svn
SVNParentPath /var/www/html/svn
#SVNPath /var/www/html/svn/main
#List repositories collection
SVNListParentPath on
SVNPathAuthz off
#Enable WebDAV automatic versioning
SVNAutoversioning on
#Repository Display Name
SVNReposName MiMedx SVN Repositories
 /Location
 ##
 
 The access_log shows:
 
 ##
 10.224.129.178 - - [02/Aug/2013:15:32:11 -0400] OPTIONS /svn/main HTTP/1.1 
 401 482 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - sgenevish [02/Aug/2013:15:32:11 -0400] OPTIONS /svn/main 
 HTTP/1.1 301 323 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - - [02/Aug/2013:15:32:11 -0400] OPTIONS /svn/main HTTP/1.1 
 401 482 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - sgenevish [02/Aug/2013:15:32:11 -0400] OPTIONS /svn/main 
 HTTP/1.1 301 323 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - - [02/Aug/2013:15:32:12 -0400] OPTIONS /svn/main HTTP/1.1 
 401 482 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - sgenevish [02/Aug/2013:15:32:12 -0400] OPTIONS /svn/main 
 HTTP/1.1 301 323 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - - [02/Aug/2013:15:32:12 -0400] OPTIONS /svn/main HTTP/1.1 
 401 482 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - sgenevish [02/Aug/2013:15:32:12 -0400] OPTIONS /svn/main 
 HTTP/1.1 301 323 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 ##
 
 I don't think there's anything particularly relevant in httpd.conf, except 
 maybe:
 
 ##
 ServerRoot /etc/httpd
 Listen 8080
 DocumentRoot /var/www/html
 ##
 
 There are no symbolic links in the directory.
 
 Thanks,
 
 -Scott
 This email message and any attachments are for the sole use of the 
 above-named intended recipient(s). This email and any attachments are 
 confidential and proprietary to MiMedx Group, Inc. and may also contain 
 certain privileged attorney-client information. This information is intended 
 only for the use of the individual entity or intended recipient addressed 
 above. You are not to use, disclose, distribute or disseminate this email by 
 any means without the expressed permission of MiMedx Group, Inc. If you are 
 not the intended recipient, or the employee or agent responsible for 
 delivering  this email to the intended recipient, you are hereby notified 
 that any use, disclosure, printing, copying, distribution or dissemination by 
 any means of this email or any attachments is strictly prohibited. If you 
 have received this email in error, please immediately notify the sender by 
 telephone at (678) 384-6720 or by reply email and delete this email and any 
 attachments and destroy all hard copies. Thank you. 
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
 For additional commands, e-mail: users-h...@httpd.apache.org
 

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



RE: [users@httpd] Setting up Apache Subversion

2013-08-02 Thread Scott Genevish
I'm a little confused by this suggestion.  I think the RedirectMatch line is 
just redirecting URL's that have a path of /svn to /svn/ so the slash is 
added to work around the issue shown here:  
http://svn.haxx.se/users/archive-2010-06/0398.shtml

I tried changing the RedirectMatch line to:

RedirectMatch ^(/svn) $1/

And now I get:

Unable to connect to a repository at URL 'http://10.224.48.53:8080/svn/main'
Repository moved temporarily to 'http://10.224.48.53:8080/svn'; please relocate

which seems to make sense.  It's redirecting /svn/main/ to /svn/

-Scott

-Original Message-
From: Macks, Aaron [mailto:ama...@harvardbusiness.org]
Sent: Friday, August 02, 2013 4:44 PM
To: users@httpd.apache.org
Cc: users@httpd.apache.org
Subject: Re: [users@httpd] Setting up Apache Subversion

Slash versus no slash.  You're redirecting things that aren't /svn to /svn/ 
(note the trailing slash). I think if you remove the $ from the regex it should 
work A

On Aug 2, 2013, at 4:28 PM, Scott Genevish sgenev...@mimedx.com wrote:

 I'm getting an error when I try to checkout a subversion repository, 
 Redirect cycle detected for URL 'http://10.224.48.53:8080/svn/main'.  This 
 seems to be a misconfiguration in Apache, which is why I came here, but 
 please correct me if I'm wrong.

 The key sections of the subversion.conf are:

 ###
 # Work around authz and SVNListParentPath issue RedirectMatch ^(/svn)$
 $1/

 Location /svn/
DAV svn
SVNParentPath /var/www/html/svn
#SVNPath /var/www/html/svn/main
#List repositories collection
SVNListParentPath on
SVNPathAuthz off
#Enable WebDAV automatic versioning
SVNAutoversioning on
#Repository Display Name
SVNReposName MiMedx SVN Repositories
 /Location
 ##

 The access_log shows:

 ##
 10.224.129.178 - - [02/Aug/2013:15:32:11 -0400] OPTIONS /svn/main HTTP/1..1 
 401 482 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - sgenevish [02/Aug/2013:15:32:11 -0400] OPTIONS /svn/main 
 HTTP/1.1 301 323 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - - [02/Aug/2013:15:32:11 -0400] OPTIONS /svn/main HTTP/1..1 
 401 482 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - sgenevish [02/Aug/2013:15:32:11 -0400] OPTIONS /svn/main 
 HTTP/1.1 301 323 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - - [02/Aug/2013:15:32:12 -0400] OPTIONS /svn/main HTTP/1..1 
 401 482 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - sgenevish [02/Aug/2013:15:32:12 -0400] OPTIONS /svn/main 
 HTTP/1.1 301 323 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - - [02/Aug/2013:15:32:12 -0400] OPTIONS /svn/main HTTP/1..1 
 401 482 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - sgenevish [02/Aug/2013:15:32:12 -0400] OPTIONS /svn/main 
 HTTP/1.1 301 323 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 ##

 I don't think there's anything particularly relevant in httpd.conf, except 
 maybe:

 ##
 ServerRoot /etc/httpd
 Listen 8080
 DocumentRoot /var/www/html
 ##

 There are no symbolic links in the directory.

 Thanks,

 -Scott
 This email message and any attachments are for the sole use of the 
 above-named intended recipient(s). This email and any attachments are 
 confidential and proprietary to MiMedx Group, Inc. and may also contain 
 certain privileged attorney-client information. This information is intended 
 only for the use of the individual entity or intended recipient addressed 
 above. You are not to use, disclose, distribute or disseminate this email by 
 any means without the expressed permission of MiMedx Group, Inc. If you are 
 not the intended recipient, or the employee or agent responsible for 
 delivering  this email to the intended recipient, you are hereby notified 
 that any use, disclosure, printing, copying, distribution or dissemination by 
 any means of this email or any attachments is strictly prohibited. If you 
 have received this email in error, please immediately notify the sender by 
 telephone at (678) 384-6720 or by reply email and delete this email and any 
 attachments and destroy all hard copies. Thank you.




 -
 To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
 For additional commands, e-mail: users-h...@httpd.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

This email message and any attachments are for the sole use of the above-named 
intended recipient(s). This email and any attachments are confidential 

RE: [users@httpd] Setting up Apache Subversion

2013-08-02 Thread Scott Genevish
OK, I figured out a solution based on this message:

http://tigris-scm.10930.n7.nabble.com/TortoiseSVN-1-4-0-Build-7195-fails-when-Apache-sends-301-Redirect-td39856.html

I added this line to the httpd.conf file where the other lines like it were 
placed:

BrowserMatch TortoiseSVN redirect-carefully

-Scott


-Original Message-
From: Scott Genevish [mailto:sgenev...@mimedx.com]
Sent: Friday, August 02, 2013 6:12 PM
To: users@httpd.apache.org
Subject: RE: [users@httpd] Setting up Apache Subversion

I'm a little confused by this suggestion.  I think the RedirectMatch line is 
just redirecting URL's that have a path of /svn to /svn/ so the slash is 
added to work around the issue shown here:  
http://svn.haxx.se/users/archive-2010-06/0398.shtml

I tried changing the RedirectMatch line to:

RedirectMatch ^(/svn) $1/

And now I get:

Unable to connect to a repository at URL 'http://10.224.48.53:8080/svn/main'
Repository moved temporarily to 'http://10.224.48.53:8080/svn'; please relocate

.which seems to make sense.  It's redirecting /svn/main/ to /svn/

-Scott

-Original Message-
From: Macks, Aaron [mailto:ama...@harvardbusiness.org]
Sent: Friday, August 02, 2013 4:44 PM
To: users@httpd.apache.org
Cc: users@httpd.apache.org
Subject: Re: [users@httpd] Setting up Apache Subversion

Slash versus no slash.  You're redirecting things that aren't /svn to /svn/ 
(note the trailing slash). I think if you remove the $ from the regex it should 
work A

On Aug 2, 2013, at 4:28 PM, Scott Genevish sgenev...@mimedx.com wrote:

 I'm getting an error when I try to checkout a subversion repository, 
 Redirect cycle detected for URL 'http://10.224.48.53:8080/svn/main'.  This 
 seems to be a misconfiguration in Apache, which is why I came here, but 
 please correct me if I'm wrong.

 The key sections of the subversion.conf are:

 ###
 # Work around authz and SVNListParentPath issue RedirectMatch ^(/svn)$
 $1/

 Location /svn/
DAV svn
SVNParentPath /var/www/html/svn
#SVNPath /var/www/html/svn/main
#List repositories collection
SVNListParentPath on
SVNPathAuthz off
#Enable WebDAV automatic versioning
SVNAutoversioning on
#Repository Display Name
SVNReposName MiMedx SVN Repositories
 /Location
 ##

 The access_log shows:

 ##
 10.224.129.178 - - [02/Aug/2013:15:32:11 -0400] OPTIONS /svn/main 
 HTTP/1...1 401 482 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - sgenevish [02/Aug/2013:15:32:11 -0400] OPTIONS /svn/main 
 HTTP/1.1 301 323 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - - [02/Aug/2013:15:32:11 -0400] OPTIONS /svn/main 
 HTTP/1...1 401 482 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - sgenevish [02/Aug/2013:15:32:11 -0400] OPTIONS /svn/main 
 HTTP/1.1 301 323 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - - [02/Aug/2013:15:32:12 -0400] OPTIONS /svn/main 
 HTTP/1...1 401 482 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - sgenevish [02/Aug/2013:15:32:12 -0400] OPTIONS /svn/main 
 HTTP/1.1 301 323 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - - [02/Aug/2013:15:32:12 -0400] OPTIONS /svn/main 
 HTTP/1...1 401 482 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 10.224.129.178 - sgenevish [02/Aug/2013:15:32:12 -0400] OPTIONS /svn/main 
 HTTP/1.1 301 323 - SVN/1.7.10/TortoiseSVN-1.7.13.24257 neon/0.29.6
 ##

 I don't think there's anything particularly relevant in httpd.conf, except 
 maybe:

 ##
 ServerRoot /etc/httpd
 Listen 8080
 DocumentRoot /var/www/html
 ##

 There are no symbolic links in the directory.

 Thanks,

 -Scott
 This email message and any attachments are for the sole use of the 
 above-named intended recipient(s). This email and any attachments are 
 confidential and proprietary to MiMedx Group, Inc. and may also contain 
 certain privileged attorney-client information. This information is intended 
 only for the use of the individual entity or intended recipient addressed 
 above. You are not to use, disclose, distribute or disseminate this email by 
 any means without the expressed permission of MiMedx Group, Inc. If you are 
 not the intended recipient, or the employee or agent responsible for 
 delivering  this email to the intended recipient, you are hereby notified 
 that any use, disclosure, printing, copying, distribution or dissemination by 
 any means of this email or any attachments is strictly prohibited. If you 
 have received this email in error, please immediately notify the sender by 
 telephone at (678) 384-6720 or by reply email and delete this email and any 
 attachments and destroy all hard copies. Thank you.




 

Re: [users@httpd] Setting up Apache Subversion

2013-08-02 Thread Ben Reser
On Fri, Aug 2, 2013 at 3:26 PM, Scott Genevish sgenev...@mimedx.com wrote:
 OK, I figured out a solution based on this message:

 http://tigris-scm.10930.n7.nabble.com/TortoiseSVN-1-4-0-Build-7195-fails-when-Apache-sends-301-Redirect-td39856.html

 I added this line to the httpd.conf file where the other lines like it were 
 placed:

 BrowserMatch TortoiseSVN redirect-carefully

That's going to break with other svn clients like the command line
client.  I think matching on SVN/ should get most SVN clients
including TortoiseSVN (at least we include SVN/ in the useragent of
the libraries).  There are of course other implementations of SVN
(e.g. SVNKit) that may not necessarily match this but as far as I know
they also comply with this convention.

The better recommendation here is to simply not use redirects at all.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org