Subject: [scim] multiple multi valued attributes set to primary = true

From: Shelley <[email-masked]>
Date: Mon, 20 Jan 2014 10:15:50 -0600

Note that this was previously discussed briefly in this thread [1] as well.

+1 to failing with a *400 Bad Request *if multiple "true" primary values
are provided.

-1 to 409. This status is generally used to indicate a conflict with an
existing resource on the server. In this case, the resource itself is not
duplicated; just bad attributes within the resource are provided (i.e. it
is a bad request which violates schema, rather than a conflict which
duplicates a resource).

-1 to 422. Although this status code may be appropriate, the SCIM spec *already
uses 400s *for the general purpose of indicating bad requests from the
client, not only limited to invalid syntax (i.e. bad requests) but also
invalid semantics (i.e. unprocessable entities) [2].

For what it's worth, In our current SCIM 1.1 SP implementation, we are
using 400s for this condition.

[1] http://www.ietf.org/mail-archive/web/scim/current/msg01057.html
[2] http://www.simplecloud.info/specs/draft-scim-api-01.html
<http://www.ietf.org/mail-archive/web/scim/current/msg01059.html>

---------- Forwarded message ----------
> From: Julian Reschke <[email-masked]>
> To: Thomas Krille <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc:
> Date: Mon, 20 Jan 2014 16:20:21 +0100
> Subject: Re: [scim] multiple multi valued attributes set to primary = true
> On 2014-01-20 16:15, Thomas Krille wrote:
>
>> 2014/1/20 Julian Reschke <[email-masked]
>> <mailto:[email-masked]>>
>>
>>     A 4xx makes sense. 409 does not really ("The 409 (Conflict) status
>>     code indicates that the request could not be completed due to a
>>     conflict with the current state of the target resource.").
>>
>>     422 might be applicable.
>>
>>
>> 422 would be nice, but it is defined by the WebDAV HTTP extensions, that
>> do not apply here (we don't make no WebDAV). 400 seems to be the only
>>
>
> The status code can be used independently of WebDAV (check the
> definition). There's a reason why we have a protocol-independent registry
> of status codes, after all.
>
>  ...
>>
>
> Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Jan 2014 17:26:28 +0100

> +1 to failing with a *400 Bad Request *if multiple "true" primary values

Yes, it needs to be 400 or something more specific.

> existing resource on the server. In this case, the resource itself is
> not duplicated; just bad attributes within the resource are provided
> (i.e. it is a bad request which violates schema, rather than a conflict
> which duplicates a resource).

Correct, 409 is the wrong code if the message itself has a problem.

> -1 to 422. Although this status code may be appropriate, the SCIM spec
> /already uses 400s /for the general purpose of indicating bad requests
> from the client, not only limited to invalid syntax (i.e. bad requests)
> but also invalid semantics (i.e. unprocessable entities) [2].

Well, the same argument pro 422 applies to the other cases as well. And 
yes, consistency is good.

Anyway, this is another example why profiling is bad. If somebody 
defines a more specific status code that would make sense but the spec 
already REQUIREs 400 you're screwed.

Best regards, Julian