You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Aaron V. Humphrey" <aa...@investopedia.com> on 2011/12/01 23:34:11 UTC
"400 Bad Request" on commit with 1.7 client to 1.7 server
We recently set up a new SVN 1.7.1 server, using CollabNet Subversion Edge 2.1.
We seemed to be able to connect to it properly using TortoiseSVN 1.6 clients,
and version 1.7 clients (both TortoiseSVN and Cygwin command-line) were able to
use any command which did not try to update the repository. However, trying to
do a simple commit failed with the following error message:
Server sent unexpected return value (400 Bad Request) in response to POST
request for '/svn/<reposname>/!svn/me'
In the access.log file on the server was the following line:
192.168.34.141 - <username> [01/Dec/2011:15:14:38 -0700] "POST
/svn/<reposname>/!svn/me HTTP/1.1" 400 226
which wasn't very helpful. I turned up Apache logging on the server to
"LogLevel debug" and got a lot of information, but nothing that seemed too
helpful either.
We are using https: to access to repository. It does give a warning because I
am using the default "svnedge.collab.net" server certificate, but I asked it to
accept it permanently the first time. Among the debug information it gives is
"SSL negotation finished successfully", too.
Based on a post from last week, I tried adding
SVNAdvertiseV2Protocol off
to my httpd.conf under <Location />, but it didn't seem to help.
Let me know what other information I can provide to try to resolve this.
Aaron V. Humphrey
Web Developer
Investopedia.com
Re: "400 Bad Request" on commit with 1.7 client to 1.7 server
Posted by Gustavo Chaves <gu...@cpqd.com.br>.
Just one more information. I was using the packages
CollabNetSubversion-extras and CollabNetSubversion-server version
1.7.0-2. I've just upgrade them to version 1.7.1-1 but the problems
remain.
--
Gustavo.
Re: "400 Bad Request" on commit with 1.7 client to 1.7 server
Posted by Gustavo Chaves <gu...@cpqd.com.br>.
On 1 dez, 22:29, Mark Phippard <ma...@gmail.com> wrote:
>
> Subversion Edge does not have the location block for SVN in the
> httpd.conf file. Have you customized the configuration files beyond
> this? There is no reason you should have to add that directive
> anyway.
>
> Assuming you are using the default configuration that SVN Edge writes,
> which I know works properly, have you defined any authz rules in the
> "Access Rules" section of the Repositories tab? If so, maybe
> temporarily replace the rules with:
>
> [/]
> * = rw
>
> And see if that solves anything.
I'm having the same problem but I'm not using Subversion Edge. I'm
using the CollabNetSubversion-server-1.7.0-2 RPM package. The problem
occurs trying to commit either via https or http. Setting "LogLevel
debug" doesn't show anything usefull in the log file.
My connection is direct, with no proxy in between client and server.
My Location directive is this:
<Location /admin>
DAV svn
SVNPath /l/home1/svn/admin/admin
Require user gustavo
</Location>
The authentication is configured in a <Directory /> directive using
LDAP. The authentication works because I can checkout, ls, and update
the repository. It seems that it's just the commit that is causing
problems.
I've tried to use a AuthzSVNAccessFile directive in the location and
set the authz file so that my user (gustavo) have full rights, but it
didn't solve the problem.
I don't have any other idea...
Gustavo.
Re: "400 Bad Request" on commit with 1.7 client to 1.7 server
Posted by Gustavo Chaves <gu...@cpqd.com.br>.
On 5 dez, 09:13, Philip Martin <ph...@wandisco.com> wrote:
> Your problem with POST requests is not yet understood. It's might be
> some overlap between Subversion directives in your apache config, or
> between Subversion directives and non-Subversion directives. Only you
> can really identify the problem at present, unless you post enough
> information for somebody else to reproduce the problem.
Thank you, Philip, for confirming my suspicions.
I'll follow your advice and try to strip down my configuration until
it starts working. I'll post here my results as I get them.
--
Gustavo.
Re: "400 Bad Request" on commit with 1.7 client to 1.7 server
Posted by Philip Martin <ph...@wandisco.com>.
Gustavo Chaves <gu...@cpqd.com.br> writes:
> However, I understand that by turning that option Off I'm telling
> apache to use the old HTTP protocol, giving up on the new one that is
> much more performant, right?
Yes.
> Regarding the 1.7.2 release, I understand that it should appear
> shortly. However, what I get from the changelog working (make
> mod_dav_svn ignore non-Subversion POST requests) is that the server
> would ignore POST requests from non-Subversion clients. But I'm doing
> commits with the CollabNet's svn command version 1.7.1, not from any
> browser or other client. Shouldn't those POSTS be regarded as
> Subversion ones and not be ignored?
Yes. The strace you posted showed the POST reaching the mod_dav_svn
Apache module.
1.7.1 has a bug that Subversion attempts to handle *all* POST requests,
including those not targeted at Subversion repositories, and when it
receives a non-Subversion POST request it returns an error that prevents
non-Subversion processing. This bug is fixed in 1.7.2.
Your problem with POST requests is not yet understood. It's might be
some overlap between Subversion directives in your apache config, or
between Subversion directives and non-Subversion directives. Only you
can really identify the problem at present, unless you post enough
information for somebody else to reproduce the problem.
One way to track down the problem is start with a small Apache config
file that works and gradually expand it until it stops working. Or to
gradually strip down the non-working file until it works.
--
Philip
Re: "400 Bad Request" on commit with 1.7 client to 1.7 server
Posted by Gustavo Chaves <gu...@cpqd.com.br>.
On 5 dez, 05:59, Konstantin Kolinko <kn...@gmail.com> wrote:
> 2011/12/4 Gustavo Chaves <gu...@cpqd.com.br>:
>
> There are known problems with handling of POST requests in 1.7.0 an 1.7.1.
>
> In 1.7.2 changes list that is mentioned as
> * make mod_dav_svn ignore non-Subversion POST requests (r1187695)
>
> The POST request are from the new version of SVN HTTP protocol (aka
> "version 2") added in 1.7. It can be turned off in configuration,
> SVNAdvertiseV2Protocol Offhttp://svnbook.red-bean.com/en/1.7/svn.ref.mod_dav_svn.conf.html
That solved the problem. Thank you!
However, I understand that by turning that option Off I'm telling
apache to use the old HTTP protocol, giving up on the new one that is
much more performant, right? Without the new protocol I'll not be able
to move everyone from svnserve to HTTP as I'd like to do.
Regarding the 1.7.2 release, I understand that it should appear
shortly. However, what I get from the changelog working (make
mod_dav_svn ignore non-Subversion POST requests) is that the server
would ignore POST requests from non-Subversion clients. But I'm doing
commits with the CollabNet's svn command version 1.7.1, not from any
browser or other client. Shouldn't those POSTS be regarded as
Subversion ones and not be ignored?
Thanks again.
--
Gustavo.
Re: "400 Bad Request" on commit with 1.7 client to 1.7 server
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/12/4 Gustavo Chaves <gu...@cpqd.com.br>:
> I straced the httpd daemon to try to get any hint. The last syscalls
> before the error are these:
>
> 17748 read(18, "POST /admin/!svn/me HTTP/1.1\r\nUs"..., 8000) = 441
There are known problems with handling of POST requests in 1.7.0 an 1.7.1.
In 1.7.2 changes list that is mentioned as
* make mod_dav_svn ignore non-Subversion POST requests (r1187695)
The POST request are from the new version of SVN HTTP protocol (aka
"version 2") added in 1.7. It can be turned off in configuration,
SVNAdvertiseV2Protocol Off
http://svnbook.red-bean.com/en/1.7/svn.ref.mod_dav_svn.conf.html
Best regards,
Konstantin Kolinko
Re: "400 Bad Request" on commit with 1.7 client to 1.7 server
Posted by Gustavo Chaves <gu...@cpqd.com.br>.
I straced the httpd daemon to try to get any hint. The last syscalls
before the error are these:
17748 read(18, "POST /admin/!svn/me HTTP/1.1\r\nUs"..., 8000) = 441
17748 stat("/l/home1/svn/admin/htdocs/admin/!svn/me", 0x7fffce99c130)
= -1 ENOENT (No such file or directory)
17748 lstat("/l", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
17748 lstat("/l/home1", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
17748 lstat("/l/home1/svn", {st_mode=S_IFDIR|0775, st_size=4096, ...})
= 0
17748 lstat("/l/home1/svn/admin", {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
17748 lstat("/l/home1/svn/admin/htdocs", {st_mode=S_IFDIR|0775,
st_size=4096, ...}) = 0
17748 lstat("/l/home1/svn/admin/htdocs/admin", 0x7fffce99c130) = -1
ENOENT (No such file or directory)
17748 write(9, "[Sun Dec 04 14:58:00 2011] [debu"..., 207) = 207
17748 semop(5996545, 0x2b526524e160, 1) = 0
17748 semop(5996545, 0x2b526524e16c, 1) = 0
17748 semop(5996545, 0x2b526524e160, 1) = 0
17748 semop(5996545, 0x2b526524e16c, 1) = 0
17748 write(9, "[Sun Dec 04 14:58:00 2011] [debu"..., 133) = 133
17748 write(9, "[Sun Dec 04 14:58:00 2011] [debu"..., 158) = 158
17748 open("/l/home1/svn/admin/admin/db/current", O_RDONLY) = 20
17748 fcntl(20, F_GETFD) = 0
17748 fcntl(20, F_SETFD, FD_CLOEXEC) = 0
17748 read(20, "1\n", 4096) = 2
17748 close(20) = 0
17748 writev(18, [{"HTTP/1.1 400 Bad Request\r\nDate: "..., 226}, {"<!
DOCTYPE HTML PUBLIC \"-//IETF//"..., 226}], 2) = 452
I suppose the initial lstats are from httpd trying first to see if the
URL points to a file and only after failing that it realizes that the
path /admin is a specific Location. Anyway, the last open finds the
correct file in the repository and reads it. I can't see anything to
justify the error message in the last line.
This is a solitary repository configured with a SVNPath directive.
Since I have other repositories under a parent path I tried to perform
commits to one of them and got another error message:
$ svn info | grep URL
URL: http://svn2.cpqd.com.br/svn/xpto/trunk
$ svn ci -mx
svn: E175002: Commit failed (details follow):
svn: E175002: Server sent unexpected return value (500 Internal
Server Error) in response to POST request for '/svn/xpto/!svn/me'
This time the following line appeared in the error.log:
[Sun Dec 04 15:05:37 2011] [info] [client 192.168.100.37] Access
granted: 'gustavo' POST xpto:
[Sun Dec 04 15:05:37 2011] [error] [client 192.168.100.37]
(20014)Internal error: Can't open file '/l/home1/svn/admin/repos/svn/
format': No such file or directory
Here there's something strange. The repository is in /l/home1/svn/
admin/repos/xpto but the path shown in the log message substitutes
'repos/svn' for 'repos/xpto'.
The apache configuration is this:
<Location /svn>
DAV svn
SVNParentPath /l/home1/svn/admin/repos
SVNListParentPath on
AuthzSVNAccessFile /l/home1/svn/admin/admin/conf/authz.txt
</Location>
Stracing this commit show the following:
17757 read(18, "POST /svn/xpto/!svn/me HTTP/1.1\r"..., 8000) = 444
17757 stat("/l/home1/svn/admin/htdocs/svn/xpto/!svn/me",
0x7fffce99c150) = -1 ENOENT (No such file or directory)
17757 lstat("/l", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
17757 lstat("/l/home1", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
17757 lstat("/l/home1/svn", {st_mode=S_IFDIR|0775, st_size=4096, ...})
= 0
17757 lstat("/l/home1/svn/admin", {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
17757 lstat("/l/home1/svn/admin/htdocs", {st_mode=S_IFDIR|0775,
st_size=4096, ...}) = 0
17757 lstat("/l/home1/svn/admin/htdocs/svn", 0x7fffce99c150) = -1
ENOENT (No such file or directory)
17757 write(9, "[Sun Dec 04 14:54:18 2011] [debu"..., 207) = 207
17757 semop(5996545, 0x2b526524e160, 1) = 0
17757 semop(5996545, 0x2b526524e16c, 1) = 0
17757 semop(5996545, 0x2b526524e160, 1) = 0
17757 semop(5996545, 0x2b526524e16c, 1) = 0
17757 write(9, "[Sun Dec 04 14:54:18 2011] [debu"..., 133) = 133
17757 write(9, "[Sun Dec 04 14:54:18 2011] [debu"..., 168) = 168
17757 write(9, "[Sun Dec 04 14:54:18 2011] [info"..., 95) = 95
17757 open("/l/home1/svn/admin/repos/svn/format", O_RDONLY) = -1
ENOENT (No such file or directory)
17757 write(9, "[Sun Dec 04 14:54:18 2011] [erro"..., 163) = 163
17757 writev(18, [{"HTTP/1.1 500 Internal Server Err"..., 236}, {"<!
DOCTYPE HTML PUBLIC \"-//IETF//"..., 539}], 2) = 775
It tries to open "/l/home1/svn/admin/repos/svn/format" instead of "/l/
home1/svn/admin/repos/xpto/format", but I don't understand why.
Again, I can browse the repositories, checkout, update and ls them. I
just can't commit anything to them.
I feel I'm missing something trivial, but I cannot spot it. Help! :-)
--
Gustavo.
Re: "400 Bad Request" on commit with 1.7 client to 1.7 server
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Dec 1, 2011 at 5:34 PM, Aaron V. Humphrey
<aa...@investopedia.com> wrote:
> We recently set up a new SVN 1.7.1 server, using CollabNet Subversion Edge 2.1.
> We seemed to be able to connect to it properly using TortoiseSVN 1.6 clients,
> and version 1.7 clients (both TortoiseSVN and Cygwin command-line) were able to
> use any command which did not try to update the repository. However, trying to
> do a simple commit failed with the following error message:
>
> Server sent unexpected return value (400 Bad Request) in response to POST
> request for '/svn/<reposname>/!svn/me'
>
> In the access.log file on the server was the following line:
>
> 192.168.34.141 - <username> [01/Dec/2011:15:14:38 -0700] "POST
> /svn/<reposname>/!svn/me HTTP/1.1" 400 226
>
> which wasn't very helpful. I turned up Apache logging on the server to
> "LogLevel debug" and got a lot of information, but nothing that seemed too
> helpful either.
>
> We are using https: to access to repository. It does give a warning because I
> am using the default "svnedge.collab.net" server certificate, but I asked it to
> accept it permanently the first time. Among the debug information it gives is
> "SSL negotation finished successfully", too.
>
> Based on a post from last week, I tried adding
>
> SVNAdvertiseV2Protocol off
>
> to my httpd.conf under <Location />, but it didn't seem to help.
>
> Let me know what other information I can provide to try to resolve this.
Subversion Edge does not have the location block for SVN in the
httpd.conf file. Have you customized the configuration files beyond
this? There is no reason you should have to add that directive
anyway.
Assuming you are using the default configuration that SVN Edge writes,
which I know works properly, have you defined any authz rules in the
"Access Rules" section of the Repositories tab? If so, maybe
temporarily replace the rules with:
[/]
* = rw
And see if that solves anything.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/