Return-Path: X-Original-To: apmail-subversion-dev-archive@minotaur.apache.org Delivered-To: apmail-subversion-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 867DF10AA7 for ; Mon, 3 Jun 2013 23:11:22 +0000 (UTC) Received: (qmail 467 invoked by uid 500); 3 Jun 2013 23:11:22 -0000 Delivered-To: apmail-subversion-dev-archive@subversion.apache.org Received: (qmail 413 invoked by uid 500); 3 Jun 2013 23:11:22 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 405 invoked by uid 99); 3 Jun 2013 23:11:22 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Jun 2013 23:11:22 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of gstein@gmail.com designates 209.85.212.175 as permitted sender) Received: from [209.85.212.175] (HELO mail-wi0-f175.google.com) (209.85.212.175) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Jun 2013 23:11:14 +0000 Received: by mail-wi0-f175.google.com with SMTP id hn14so3210697wib.2 for ; Mon, 03 Jun 2013 16:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YH7INwIvv52Kh1UgmIsg4NNSuh9M3dLiXTbRT0EAPEw=; b=tlUT5SxteGjuMY0+H1/ZDa+uxL+0pSCkXylWSBCISZTn3SmCSwWOPZZsKsVjswoUk6 7AEjEcrBcRY9k3vMRHkqC5hp8ayDbzwIc94FIhPUUcUBxC4ZCL1V4o/LAbZjJVPVZAOw ofwmscCFPCPN5E8Pbtz7WYu9Ky/u5q2maZz2T1ROTxMwgeoB/+abjwOHco8GHYX5bJSY 2xClaCiOtqt6GWobhThcDpBPrAggvNq8+pnXKgXDxu0Ggl19sbj2pQIR+Z/LGMnTmMj5 xtf1LiSkvrLW1g6CPvtDXU/rU0uIguxp2kb2KmxIoIoxAPK5Rr7HR9NXyntCNaRaXYu3 zYfw== MIME-Version: 1.0 X-Received: by 10.180.21.193 with SMTP id x1mr244292wie.31.1370301054484; Mon, 03 Jun 2013 16:10:54 -0700 (PDT) Received: by 10.194.11.37 with HTTP; Mon, 3 Jun 2013 16:10:54 -0700 (PDT) In-Reply-To: References: <87y5aqgam0.fsf@ntlworld.com> <87txleg82u.fsf@ntlworld.com> Date: Mon, 3 Jun 2013 19:10:54 -0400 Message-ID: Subject: Re: serf error handling for locks without authn From: Greg Stein To: Ben Reser Cc: Philip Martin , Subversion Development Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Jun 3, 2013 at 6:48 PM, Ben Reser wrote: > On Mon, Jun 3, 2013 at 3:31 PM, Greg Stein wrote: >... >> Yeah. HTTP_CONFLICT should be correct, there. > > Well technically 401 is right but we have now way of filling in the > proper WWW-Authenticate header. HTTP_CONFLICT doesn't sound > particularly great either because that's supposed to be describing an > issue with the state of the resource. "This resource needs a username" or something like that :-) > I'd argue that we should return a 500 range error since the problem > here is that the server is not properly configured. There is really Nah. 500 means there is nothing the client can do, which isn't quite accurate. A client *could* go ahead and fill in an Authorization: header. (tho I don't know if Apache will parse it, without a config there) > nothing a client can do to resolve the issue other than to > authenticate, which our client is only going to do if the server is > setup properly. So I'd vote for returning HTTP_INTERNAL_SERVER_ERROR. "our client" won't do anything. Doesn't mean another one would. 500 is really for "holy crap. something failed, and I have NO IDEA what is going on. so just go away" That isn't really true in this case. Cheers, -g