From users-return-24155-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Tue Dec 8 15:28:33 2015 Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 29C6218213 for ; Tue, 8 Dec 2015 15:28:33 +0000 (UTC) Received: (qmail 56282 invoked by uid 500); 8 Dec 2015 15:28:32 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 56239 invoked by uid 500); 8 Dec 2015 15:28:32 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 56229 invoked by uid 99); 8 Dec 2015 15:28:32 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Dec 2015 15:28:32 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 14B3C180428 for ; Tue, 8 Dec 2015 15:28:32 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.889 X-Spam-Level: ** X-Spam-Status: No, score=2.889 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=qqmail.nl Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id uZgJ0K1GoLee for ; Tue, 8 Dec 2015 15:28:29 +0000 (UTC) Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 131FD20CB7 for ; Tue, 8 Dec 2015 15:28:29 +0000 (UTC) Received: by wmec201 with SMTP id c201so217487850wme.0 for ; Tue, 08 Dec 2015 07:28:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qqmail.nl; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=1EATRgnxmntCeThm+GKssBTihqS7wnVZFWFNeWw9zuY=; b=UPXg9nXL0pfxJynLFo1MDL7zzEqG2V8mGxbBCy3PmPmmce/iC3M6W/Q81QHYN9zjrE wLL+M07rEXHUCQ0UQgwqiguVECjLpgv3sF1ZQ+gvfUmC7FahlIj6CZF+nY8YJeIFXj+b rbJ9njPWADnQ+DRLltsby/MR3m6XCmurLm5Vc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:thread-index:content-language; bh=1EATRgnxmntCeThm+GKssBTihqS7wnVZFWFNeWw9zuY=; b=m7q54eoF7+KuGxRSmwU0VZGPN/9T+zsjQ2kOXk1Zgg5wLGLVRccJDO3rNhrMd3N+3E HYUnb2zSk6/JgVf6F3fqoZKLpi9cFBiFa928TF0cSXLK1ORss71dUDgfzzlHwKTlMvf8 9lb9ACBE2lCfzvQ4cWUo5mvduOkbSW4J+Y1n4Velm+LJqdU1boMVT6uqQTa6TAnFsfcN P6Ym3LEqxdkkDKSuH7MFYVYJFCK2q6kBogRp4cTnU6/G8cu0B53hbs7J/AtEWaiw6mDX PtNMCsVtmmmiwfJfiUgUmzcvQMeuVXueIBL93unFZjAexU1zW14+YWVdMTxqp565LKvn LKIA== X-Gm-Message-State: ALoCoQmTBPVvgDr9285OUEQbwNwf2OGs7UcEncOGhjyva+p1RdsAaXPeiS4A19uT88mdxdxjNxV1FOajRpB/Vd7WkjbNeBl67A== X-Received: by 10.28.229.15 with SMTP id c15mr29254522wmh.76.1449588508664; Tue, 08 Dec 2015 07:28:28 -0800 (PST) Received: from I72600 ([2001:610:66e:0:52e5:49ff:fee1:96b7]) by smtp.gmail.com with ESMTPSA id l20sm22018104wmd.20.2015.12.08.07.28.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Dec 2015 07:28:28 -0800 (PST) From: "Bert Huijben" To: "'Chris Capon'" , References: <56660E91.7010901@gmail.com> <566636E1.50105@acm.org> <566674FD.6050002@gmail.com> <5666E921.7080002@gmail.com> In-Reply-To: <5666E921.7080002@gmail.com> Subject: RE: Unexpected HTTP status 400 'Bad request'. Date: Tue, 8 Dec 2015 16:28:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_CF91_01D131D5.758A0670" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJTDuK3ndAsCLqZluCjXZVec57IvwHTURI8AhI5uB0CTUUaXAJ3OzAcAdN57BgCEveNVJ1Y9/bg Content-Language: nl This is a multipart message in MIME format. ------=_NextPart_000_CF91_01D131D5.758A0670 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This is just the Subversion operational log generated by mod_dav_svn. = The interesting things would be in the apache access and/or error logs. (Depending on the configuration of your apache these could be the same = logfile) =20 The operational log just shows successful Subversion operations, so that = doesn=E2=80=99t tell us much why a request failed. =20 Bert =20 =20 From: Chris Capon [mailto:ttabyss@gmail.com]=20 Sent: dinsdag 8 december 2015 15:29 To: users@subversion.apache.org Subject: Re: Unexpected HTTP status 400 'Bad request'. =20 Hi Bert. The only log I know of is under /var/log/apache2/subversion.log, and = when I issue a checkout, I get only two lines in it: [08/Dec/2015:09:24:53 -500] myself get-inherited-props /dev/trunk r3066 [08/Dec/2015:09:24:53 -500] myself checkout-or-export /dev/trunk r3066 If the error were caused by a firewall or antivirus software, would it = still make sense that the checkout begins and gets several files in = before failing? Also, to try and eliminate that possibility, I've been = performing the checkout tests on the subversion server machine. On 2015-12-08 05:37, Bert Huijben wrote: Usually you wouldn=E2=80=99t get =E2=80=98bad request=E2=80=99 errors = from httpd unless Subversion sends a bad request. Server side errors as = disk io are usually reported by other error codes, such as 500. =20 Most bad cases of status 400 are caused by firewall and antivirus = products that somehow alter requests in unexpected ways. Another = =E2=80=98expected=E2=80=99 case of this error is when Subversion sends = too many headers to the server; we see this in some commits of subtrees = with hundreds of locks. The investigation for this error code should = start in the server log. =20 Except for that too much header data, the Subversion client should never = generate a request that the server thinks is =E2=80=98bad=E2=80=99. That = is what it tells with status 400. =20 But as noted before: more details should be in the server log (and often = in the response body itself=E2=80=A6 but if there was usable data there = Subversion should have noted that) =20 Bert =20 From: Yves Martin [ = mailto:ymartin1040@gmail.com]=20 Sent: dinsdag 8 december 2015 11:06 To: users@subversion.apache.org Subject: Re: Unexpected HTTP status 400 'Bad request'. =20 Hello=E2=80=8B =20 Is your repository served read-write by other services like svnserve or = eventually through SSH in addition to Apache HTTPS access ? =20 If so you have to check your repository file permissions: owner, group = and modes (for instance g+w or g+s...) =20 I guess your repository has been created long ago with a previous = version of Subversion. What is your repository format version ? Are some revisions packed ? Use = svnadmin info. =20 Maybe you should use "svnadmin upgrade" to get some new features = properly enabled with Subversion 1.9, or even use dump/load procedure (or svnsync) to get your repository = ready (and optimized) for Subversion 1.9. =20 Regards --=20 Yves Martin =20 ------=_NextPart_000_CF91_01D131D5.758A0670 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

This is just the Subversion operational log generated by mod_dav_svn. = The interesting things would be in the apache access and/or error = logs.

(Depending on the configuration of your apache these could be the same = logfile)

 

The operational log just shows successful Subversion operations, so = that doesn=E2=80=99t tell us much why a request = failed.

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Bert

 

 

From: Chris Capon [mailto:ttabyss@gmail.com]
Sent: dinsdag 8 = december 2015 15:29
To: = users@subversion.apache.org
Subject: Re: Unexpected HTTP = status 400 'Bad request'.

 

Hi = Bert.
The only log I know of is under = /var/log/apache2/subversion.log, and when I issue a checkout, I get only = two lines in it:

[08/Dec/2015:09:24:53  -500] myself = get-inherited-props /dev/trunk r3066
[08/Dec/2015:09:24:53  = -500] myself checkout-or-export /dev/trunk r3066

If the error = were caused by a firewall or antivirus software, would it still make = sense that the checkout begins and gets several files in before = failing?  Also, to try and eliminate that possibility, I've been = performing the checkout tests on the subversion server = machine.

On 2015-12-08 05:37, Bert Huijben = wrote:

Usually you wouldn=E2=80=99t get =E2=80=98bad request=E2=80=99 errors = from httpd unless Subversion sends a bad request. Server side errors as = disk io are usually reported by other error codes, such as = 500.

 

Most bad cases of status 400 are caused by firewall and antivirus = products that somehow alter requests in unexpected ways. Another = =E2=80=98expected=E2=80=99 case of this error is when Subversion sends = too many headers to the server; we see this in some commits of subtrees = with hundreds of locks. The investigation for this error code should = start in the server log.

 

Except for that too much header data, the Subversion client should = never generate a request that the server thinks is = =E2=80=98bad=E2=80=99. That is what it tells with status = 400.

 

But as noted before: more details should be in the server log (and = often in the response body itself=E2=80=A6 but if there was usable data = there Subversion should have noted that)

 

            =     Bert

 

From:<= /b> = Yves Martin [mailto:ymarti= n1040@gmail.com] =
Sent: dinsdag 8 december 2015 11:06
To: users@subvers= ion.apache.org
Subjec= t: Re: Unexpected HTTP status 400 'Bad = request'.

 

 Hello=E2=80=8B

 

Is your repository served read-write by other services = like svnserve or eventually through SSH in addition to Apache HTTPS = access ?

 

If so you have to check your repository file = permissions: owner, group and modes (for instance g+w or = g+s...)

 

I = guess your repository has been created long ago with a previous version = of Subversion.

What is = your repository format version ? Are some revisions packed ? Use = svnadmin info.

 

Maybe you should use "svnadmin upgrade" to = get some new features properly enabled with Subversion = 1.9,

or even use dump/load = procedure (or svnsync) to get your repository ready (and optimized) for = Subversion 1.9.

 

Regards

-- 

Yves = Martin

 

------=_NextPart_000_CF91_01D131D5.758A0670--