You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Steve Peterson <st...@zpfe.com> on 2006/09/05 22:06:51 UTC
400 bad request from client
I'm trying to troubleshoot an issue that I'm having both with
Subclipse and RapidSVN that looks to be a lower level protocol
problem in common with both applications.
The errors manifest themselves like this:
RapidSVN:
Execute: Checkout
Error while performing action: REPORT request failed on
'/LNSS/!svn/vcc/default'
REPORT of '/LNSS/!svn/vcc/default': 400 Bad Request (http://svn.lifetouch.net)
Ready
Subclipse
checkout -r HEAD http://svn.lifetouch.net/LNSS/account-management/src
RA layer request failed
svn: REPORT request failed on '/LNSS/!svn/vcc/default'
svn: REPORT of '/LNSS/!svn/vcc/default': 400 Bad Request
(http://svn.lifetouch.net)
The named URL can be checked out successfully on other machines and
can be browsed via the SVN Repository Exploring view and via the
RapidSVN bookmarks pane.
I sniffed the traffic between the client and server and the error
seems to occur after authentication occurs, during the following
exchange. Note the missing closing > in both hunks of XML. The same
behavior is repeatable and occurs with both clients.
The trace:
...
REPORT /LNSS/!svn/vcc/default HTTP/1.1
Host: svn.lifetouch.net
User-Agent: SVN/1.3.2 (r19776) neon/0.25.5
Connection: TE
TE: trailers
Content-Length: 236
Content-Type: text/xml
Accept-Encoding: gzip
Accept-Encoding: gzip
Authorization: Basic xxx=
<S:update-report send-all="true"
xmlns:S="svn:"><S:src-path>http://svn.lifetouch.net/LNSS/account-management/src</S:src-path><S:target-revision>2310</S:target-revision><S:entry
rev="2310" start-empty="true"></S:entry></S:update-report
HTTP/1.1 400 Bad Request
Date: Tue, 05 Sep 2006 21:32:00 GMT
Server: Apache/2.0.55 (Win32) mod_auth_sspi/1.0.3 SVN/1.3.0 DAV/2
Content-Length: 344
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
<hr>
<address>Apache/2.0.55 (Win32) mod_auth_sspi/1.0.3 SVN/1.3.0 DAV/2
Server at svn.lifetouch.net Port 80</address>
</body></html>
REPORT /LNSS/!svn/vcc/default HTTP/1.1
Host: svn.lifetouch.net
User-Agent: SVN/1.3.2 (r19776) neon/0.25.5
Connection: TE
TE: trailers
Content-Length: 236
Content-Type: text/xml
Accept-Encoding: gzip
Accept-Encoding: gzip
Authorization: Basic xxx=
<S:update-report send-all="true"
xmlns:S="svn:"><S:src-path>http://svn.lifetouch.net/LNSS/account-management/src</S:src-path><S:target-revision>2310</S:target-revision><S:entry
rev="2310" start-empty="true"></S:entry></S:update-report
--
The server is 1.3.0 on Apache 2.0.55 on Win32. The clients are
RapidSVN 0.9.3 (based on SVN 1.3.2) and Eclipse 3.1.2 with Subclipse
1.0.3 on Win32. The server log seems to indicate that the message is
malformed as well. The client and server are one hop apart and
there's no proxy between them.
Re: 400 bad request from client
Posted by Erik Pilz <ep...@altastrada.com>.
I received an email yesterday from the Kaspersky support team
acknowledging the defect. Here's the message in case you're interested:
--- Begin message ---
Reply:
06.09.2006, 12:06 - :
We have consulted with the developer, this is known problem of our product. This is due to the fact that HTTP analize module doesn't surrort WebDav on RFC standart (which is in current use by subversion)
It'll be fixed in the next release, now the only way to work correctly is to add the javaw.exe to the trusted zone.
Regards,
Kaspersky Lab Support Team
--- End message ---
I'm glad to learn that they're working on a fix.
Cheers,
Erik
Steve Peterson wrote:
> Thanks for the pointer to previous occurrences. It looks like
> http://svn.haxx.se/users/archive-2006-07/0424.shtml refers to a
> similar problem.
>
> I downloaded the svn binaries and ended up with the same problem, so 3
> clients exhibited the same issue.
>
> In this case, the fix was telling Kaspersky Anti-Virus 6.0 to trust
> the network traffic generated by the SVN clients when it is destined
> for my svn server. It looks like an interaction between their http
> proxy and the contents of the SVN message are causing the problem. I
> put in a help desk ticket with them to see if it can be resolved.
> More details on how to set Kaspersky to avoid the problem are
> available at
> http://www.jroller.com/page/chemeia?entry=subversion_and_kaspersky.
>
> Looking at the HTTP headers created by the SVN clients and the content
> of the message doesn't yield any obvious SVN problem to be fixed. In
> the sample below the actual length of the body is 235 octets, so it
> doesn't seem to be a problem with the Content-Length header.
>
> Steve
>
>
> At 06:45 PM 9/5/2006, you wrote:
>
>> On Sep 6, 2006, at 00:06, Steve Peterson wrote:
>>
>>> I sniffed the traffic between the client and server and the error
>>> seems to occur after authentication occurs, during the following
>>> exchange. Note the missing closing > in both hunks of XML. The
>>> same behavior is repeatable and occurs with both clients.
>>>
>>> The trace:
>>>
>>> ...
>>>
>>> REPORT /LNSS/!svn/vcc/default HTTP/1.1
>>> Host: svn.lifetouch.net
>>> User-Agent: SVN/1.3.2 (r19776) neon/0.25.5
>>> Connection: TE
>>> TE: trailers
>>> Content-Length: 236
>>> Content-Type: text/xml
>>> Accept-Encoding: gzip
>>> Accept-Encoding: gzip
>>> Authorization: Basic xxx=
>>>
>>> <S:update-report send-all="true" xmlns:S="svn:"><S:src-path> http://
>>> svn.lifetouch.net/LNSS/account-management/src </S:src-
>>> path><S:target-revision>2310</S:target-revision><S:entry
>>> rev="2310" start-empty="true"></S:entry></S:update-report
>>
>> The problem of the missing closing bracket on the XML response has
>> come up on the mailing list before but I do not remember the outcome
>> of the discussion. You may be able to find it if you search the
>> archives at http://svn.haxx.se
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 400 bad request from client
Posted by Steve Peterson <st...@zpfe.com>.
Thanks for the pointer to previous occurrences. It looks like
http://svn.haxx.se/users/archive-2006-07/0424.shtml refers to a
similar problem.
I downloaded the svn binaries and ended up with the same problem, so
3 clients exhibited the same issue.
In this case, the fix was telling Kaspersky Anti-Virus 6.0 to trust
the network traffic generated by the SVN clients when it is destined
for my svn server. It looks like an interaction between their http
proxy and the contents of the SVN message are causing the problem. I
put in a help desk ticket with them to see if it can be
resolved. More details on how to set Kaspersky to avoid the problem
are available at
http://www.jroller.com/page/chemeia?entry=subversion_and_kaspersky.
Looking at the HTTP headers created by the SVN clients and the
content of the message doesn't yield any obvious SVN problem to be
fixed. In the sample below the actual length of the body is 235
octets, so it doesn't seem to be a problem with the Content-Length header.
Steve
At 06:45 PM 9/5/2006, you wrote:
>On Sep 6, 2006, at 00:06, Steve Peterson wrote:
>
>>I sniffed the traffic between the client and server and the error
>>seems to occur after authentication occurs, during the following
>>exchange. Note the missing closing > in both hunks of XML. The
>>same behavior is repeatable and occurs with both clients.
>>
>>The trace:
>>
>>...
>>
>>REPORT /LNSS/!svn/vcc/default HTTP/1.1
>>Host: svn.lifetouch.net
>>User-Agent: SVN/1.3.2 (r19776) neon/0.25.5
>>Connection: TE
>>TE: trailers
>>Content-Length: 236
>>Content-Type: text/xml
>>Accept-Encoding: gzip
>>Accept-Encoding: gzip
>>Authorization: Basic xxx=
>>
>><S:update-report send-all="true" xmlns:S="svn:"><S:src-path>
>>http:// svn.lifetouch.net/LNSS/account-management/src </S:src-
>>path><S:target-revision>2310</S:target-revision><S:entry
>>rev="2310" start-empty="true"></S:entry></S:update-report
>
>The problem of the missing closing bracket on the XML response has
>come up on the mailing list before but I do not remember the outcome
>of the discussion. You may be able to find it if you search the
>archives at http://svn.haxx.se
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 400 bad request from client
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 6, 2006, at 00:06, Steve Peterson wrote:
> I sniffed the traffic between the client and server and the error
> seems to occur after authentication occurs, during the following
> exchange. Note the missing closing > in both hunks of XML. The
> same behavior is repeatable and occurs with both clients.
>
> The trace:
>
> ...
>
> REPORT /LNSS/!svn/vcc/default HTTP/1.1
> Host: svn.lifetouch.net
> User-Agent: SVN/1.3.2 (r19776) neon/0.25.5
> Connection: TE
> TE: trailers
> Content-Length: 236
> Content-Type: text/xml
> Accept-Encoding: gzip
> Accept-Encoding: gzip
> Authorization: Basic xxx=
>
> <S:update-report send-all="true" xmlns:S="svn:"><S:src-path> http://
> svn.lifetouch.net/LNSS/account-management/src </S:src-
> path><S:target-revision>2310</S:target-revision><S:entry
> rev="2310" start-empty="true"></S:entry></S:update-report
The problem of the missing closing bracket on the XML response has
come up on the mailing list before but I do not remember the outcome
of the discussion. You may be able to find it if you search the
archives at http://svn.haxx.se
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org