[oslc-core] Requests for unknown or unsupported properties

Tue Mar 27 12:47:08 EDT 2012

> In the example you mentioned the properties are optional.   I could see 
an
> argument for responding with 400 Bad Request when the properties are
> unknown.   But responding with 400 Bad Request when the properties are
> optional seems counter-intuitive because it implies that the client is 
at
> least partially responsible for the failure.

Any 4xx or 5xx code is inappropriate IMO, regardless of the properties 
being optional/unknown [to the server].

It's a "subtle enough" consequence of existing normative text that I would 
generally support proposals for additions of clarifying *informative* 
text.  I would have a harder time seeing the utility of adding normative 
text for this specific case (at [2] or [3]), but perhaps it has a place at 
[1].

My reasoning:
[2] and [3] both describe the semantics of the syntax in terms of what is 
to be included ("included" and "part of a member list pattern... to 
match", respectively), not in terms of what must be present.  Including 0 
things yields 0 things.  The "match" word used in [3] makes this a bit 
clearer, admittedly.
[1] (Core) allows servers to discard unknown property values.  One might 
quibble that it does not define "unknown" in this context with "hit reader 
over the head" obviousness, but it comes pretty darned close by saying "An 
OSLC Service MAY discard property values that are not part of the resource 
definition or Resource Shape known by the server. " in the very next 
sentence.

HTTP 4xx is intended for cases where the request is at fault, such that 
retrying the identical request is very unlikely to succeed (and if it did, 
it would do so only because of some third actor's requests changing the 
server's state in between attempts).  In the case under discussion, that 
is true *for the particular server implementation*, which is probably what 
Paul was thinking about.  While technically allowed, as Paul says, 
counter-intuitive (the same client request might succeed when sent to a 
different implementation, even at the same hostname/port, e.g. in a 
load-balanced scenario).  We could perhaps make our intent clearer on this 
point in [1], e.g. by adding
>>> When such property values [better: change all to 'triples' in this 
subsection] are presented by a client in a representation, the OSLC 
Service SHOULD [MUST?] NOT fail the request merely due to their presence.
I'm stopping short of actually proposing such an addition myself.  Merely 
trying to think through out loud what it might reasonably look like if 
others feel something is needed.

HTTP 5xx is intended for cases where the server is at fault, such that 
retrying the identical request is very likely to succeed (if/once the 
server-side problem/condition has been fixed).   That is true only under 
the (rather special and highly unlikely, yet theoretically possible) 
condition above where multiple implementations at different code levels 
accept requests for the same authority.

We could, I reluctantly suppose, suggest using an HTTP Warn response 
header in this case.  I think doing so would be more confusing than any 
perceived value it adds.  Implementations are already free to do so should 
their individual situation warrant it, and encouraging all clients to 
constantly be on the lookout for Warn headers they will almost never 
encounter seems like a waste of client programmers' time.  It would just 
bump up the adoption cost without wide value.

[1] 
http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;table=up;up=#Unknown_properties_and_content
> [2]
> 
http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;table=up;up=#Selective_Property_Values

> [3] http://open-services.net/bin/view/Main/OSLCCoreSpecQuery

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario

oslc-core-bounces at open-services.net wrote on 03/26/2012 03:09:32 PM:

> From: Paul McMahan/Raleigh/IBM at IBMUS
> To: Samuel Padgett/Durham/IBM at IBMUS
> Cc: oslc-core at open-services.net
> Date: 03/26/2012 04:13 PM
> Subject: Re: [oslc-core] Requests for unknown or unsupported properties
> Sent by: oslc-core-bounces at open-services.net
> 
> Sam,
> 
> In the example you mentioned the properties are optional.   I could see 
an
> argument for responding with 400 Bad Request when the properties are
> unknown.   But responding with 400 Bad Request when the properties are
> optional seems counter-intuitive because it implies that the client is 
at
> least partially responsible for the failure.
> 
> For example, if the client sent a syntactically incorrect query string 
then
> I would expect the server to return 400 Bad Request.  But in the example
> you mentioned the client is using properties that are explicitly defined 
in
> the CM specification.   For this case I could see the server possibly
> returning HTTP 5XX response code to indicate that the request is valid 
but
> the server can't support it.   However, I don't see any perfect match 
for
> this case in the standardized HTTP response codes [1].    And expecting 
the
> client to always check for 5XX to detect this special case when they are
> actually sending a valid request seems too burdensome anyway.  So IMO if
> the client includes an optional property in oslc.select, oslc.where, or
> oslc.properties then it should expect a HTTP 200 response but be 
prepared
> to deal with results that don't contain that property.
> 
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
> 
> 
> Best wishes,
> Paul McMahan
> IBM Rational
> 
> 
> 
> From:   Samuel Padgett/Durham/IBM
> To:   oslc-core at open-services.net
> Cc:   Paul McMahan/Raleigh/IBM at IBMUS
> Date:   03/26/2012 09:04 AM
> Subject:   Requests for unknown or unsupported properties
> 
> 
> I couldn't find clear guidance on how providers should respond to 
requests
> for unknown properties, for instance in an oslc.properties or 
oslc.select
> parameter. This might be a request for a non-standard property that a
> provider doesn't recognize (e.g., http://example.com/ns#customProperty) 
or
> a standard, but optional property not supported by the provider.
> 
> An example from the CM domain is state predicates, which are optional
> properties on a ChangeRequest resource [1]. How should a provider 
respond
> to these queries if it doesn't support oslc_cm:approved? (I've left the
> query parameters unescaped and omitted oslc.prefix for readability.)
> 
> http://example.com/bugs/34?oslc.properties=oslc_cm:approved
> http://example.com/bugs?oslc.select=oslc_cm:approved
> http://example.com/bugs?oslc.where=oslc_cm:approved=true
> 
> Either responding with a 400 Bad Request or simply leaving unknown
> properties out of the response seem like reasonable choices. I propose 
we
> advise providers to simply leave the unknown properties out of the
> response. This way consumers can request optional properties without 
fear
> of running into errors. In the case of the oslc.where query above,
> providers might simply return no results.
> 
> I suggest we update OSLC Core Spec Selective Property Values [2] and the
> query specification [3] with guidance.
> 
> [1]
> http://open-services.net/bin/view/Main/CmSpecificationV2?
> sortcol=table;up=#Resource_ChangeRequest
> [2]
> http://open-services.net/bin/view/Main/OslcCoreSpecification?
> sortcol=table;table=up;up=#Selective_Property_Values
> [3] http://open-services.net/bin/view/Main/OSLCCoreSpecQuery
> --
> Best Regards,
> Samuel Padgett | IBM Rational | spadgett at us.ibm.com
> 
> 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120327/f65eff83/attachment-0003.html>