[
https://issues.apache.org/jira/browse/OLINGO-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16538792#comment-16538792
]
Ralf Handl commented on OLINGO-1274:
------------------------------------
The code field in the error response is a free-form sub-status for the HTTP
status code, it is not a redundant repetition of the HTTP status code:
{quote}The value for the code name/value pair is a language-independent string.
Its value is a service-defined error code. This code serves as a sub-status for
the HTTP error code specified in the response.
{quote}
As examples apparently get more attention than the normative specification
text, we probably should change the OData specification to use
{{"code":"FOO-bar"}} instead of the misleading 501. I've created
[https://issues.oasis-open.org/browse/ODATA-1197] to track this.
One could argue that null is not a string, so Olingo should use an empty string
instead. I'm fine with null.
> URIParserError gives null response code in response body
> --------------------------------------------------------
>
> Key: OLINGO-1274
> URL: https://issues.apache.org/jira/browse/OLINGO-1274
> Project: Olingo
> Issue Type: Bug
> Components: odata2-core, odata4-client, odata4-commons, odata4-server
> Affects Versions: (Java) V4 4.4.0
> Reporter: Aarzoo Aggarwal
> Priority: Blocker
>
> We create an entity query relation like below -
> The request -
> [http://ip:host/odata/entity(x)?$filter=z%20eq%203|http://iphost/]
> Very obviously , we cannot create a filter on a single entity.But the problem
> is that the response that we recieve is as below -
> {
> "error":
> { "code": null, "message": "The system query option '$filter' is not
> allowed." }
> }
>
> We expect a valid status code to be returned here .
> Is any resolution for this issue available ?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
