Philip Martin writes:
> I'm trying to work out what this code should look like. This function
> is called after LOCK and PROPFIND, but not UNLOCK which has its own
> code. I think the function should be something like:
>
> apr_status_t errcode;
>
> if (err)
> return err;
>
> if (handl
Philip Martin writes:
> The code in libsvn_ra_serf/locks.c:determine_error looks dodgy:
>
> 213 static svn_error_t *
> 214 determine_error(svn_ra_serf__handler_t *handler,
> 215 svn_error_t *err)
> 216 {
> 217 {
> 218 apr_status_t errcode;
> 219
> 220 if (handler-
On Mon, Jun 3, 2013 at 5:24 PM, Konstantin Kolinko
wrote:
> If you are considering 501 then there also exists 405 Method Not Allowed
> An implementation difference though is that 405 must be accompanied by
> an Allow header.
>
> Difference between 405 and 501 is also specified in ch.5.1.1 of RFC
>
2013/6/4 Greg Stein :
> On Mon, Jun 3, 2013 at 7:10 PM, Greg Stein wrote:
>> On Mon, Jun 3, 2013 at 6:48 PM, Ben Reser wrote:
>>...
>>> 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
On Mon, Jun 3, 2013 at 7:47 PM, Philip Martin
wrote:
>...
> However there is another HTTP_UNAUTHORIZED: mod_dav_svn returns it from
> lock.c:refresh_locks:
>
> /* Sanity check: does the incoming token actually represent the
> current lock on the incoming resource? */
> if ((! slock)
>
Greg Stein writes:
> On IRC, Ben and I tossed this around. The short answer is "the server
> is not configured to allow a LOCK operation." 501 (Not Implemented)
> states it is an appropriate status when the server is unable to
> support the request method.
>
> We can also adjust the error string
On Mon, Jun 3, 2013 at 7:10 PM, Greg Stein wrote:
> On Mon, Jun 3, 2013 at 6:48 PM, Ben Reser wrote:
>...
>> 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 c
Ben Reser writes:
> That's my fault, I fixed the anonymous locking segfault and chose a
> 401 to return but I forgot about the WWW-Authenticate header
> requirement.
Not really your fault, even before your r1455352 mod_dav_svn returned
401. Without r1455352 append_locks calls svn_repos_fs_lock
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
> parti
On Mon, Jun 3, 2013 at 3:31 PM, Greg Stein wrote:
> On Mon, Jun 3, 2013 at 6:09 PM, Philip Martin
> wrote:
>> Greg Stein writes:
>>
>>> On Mon, Jun 3, 2013 at 5:14 PM, Philip Martin
>>> wrote:
http://subversion.tigris.org/issues/show_bug.cgi?id=4368
Locking with anonymous http fa
On Mon, Jun 3, 2013 at 6:09 PM, Philip Martin
wrote:
> Greg Stein writes:
>
>> On Mon, Jun 3, 2013 at 5:14 PM, Philip Martin
>> wrote:
>>> http://subversion.tigris.org/issues/show_bug.cgi?id=4368
>>>
>>> Locking with anonymous http fails because there is no username. At
>>
>> That should be all
Greg Stein writes:
> On Mon, Jun 3, 2013 at 5:14 PM, Philip Martin
> wrote:
>> http://subversion.tigris.org/issues/show_bug.cgi?id=4368
>>
>> Locking with anonymous http fails because there is no username. At
>
> That should be allowed. A WebDAV lock does not require an owner.
svn_fs_lock requ
On Mon, Jun 3, 2013 at 5:14 PM, Philip Martin
wrote:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4368
>
> Locking with anonymous http fails because there is no username. At
That should be allowed. A WebDAV lock does not require an owner.
> present mod_dav_svn returns "401 Unathorized"
13 matches
Mail list logo
