You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@olingo.apache.org by Ronny Bremer <rb...@almanid.com> on 2015/08/07 13:49:55 UTC
Kendo UI and $filter encoding
We are currently in a ping pong email thread with the support guys from Telerik about an issue, which I need to ask the Olingo experts about.
Kendo UI is being used as an OData consumer, version 2 of the standard. When Kendo UI generates a $filter query URL (they actually let JQuery handle this) it will look like this:
http://xxx.com/OData.svc/Cars&$filter=Name eq ‘YYyy’
So far it looks good, however, this is what will end up on the wire:
http://xxx.com/OData.svc/Cars&%27filter=Name+eq+%24YYyy%24
Now Olingo has a problem decoding that and throws an InvalidFilter exception. The reason is the “+” sign as a separator between the filter items. If I replace them manually with %20 everything works as expected.
I did check the OData specification, unfortunately they only show the filter URL before the encoding. According the the HTTP Standard the www-url-encoding for HTML forms (!) replaces a space with a “+” in the URL, but I fail to see why an OData query should be encoded like a HTTP form.
Telerik refers to the HTTP standard specification 4.0.1, where a “+” is the legal substitute for spaces. Is that really the case? I am not sure.
So my question is, is Telerik right with its interpretation and therefore Olingo makes a mistake or is the “+” sign really is an invalid character in the URL?
Well, in case Olingo handles it incorrectly, what would be the best way to fix it? :)
Thank you for your time,
Ronny
Re: Kendo UI and $filter encoding
Posted by Ronny Bremer <rb...@almanid.com>.
> On 10 Aug 2015, at 08:47, Bolz, Michael <mi...@sap.com> wrote:
>
> Hi Ronny,
>
>> I fully understand, that OLingo is following the standard, however, would it make sense to introduce a parameter to turn on or off support for the “+” separator in the library?
>
> I see the benefit to support such additional convenience, but in a core library for a specification it is no “must be” (IMHO).
> My suggestion is to create an according issue [1] and ideally attach a solution based on your suggestion with the “additional parameter”.
> I can not promise that this will get in the next release, however I will take a look into it.
>
Absolutely, it would only be a convenience option for OLingo based server developers to circumvent a shortcoming on the client side, definitely not a must be. I will open an issue in jira. Thank you Michael.
Yours,
Ronny
> Best Regards,
> Michael
>
> [1]: https://issues.apache.org/jira/browse/OLINGO
>
>> A bit along the line of the GSon Parameter to “try to support” not-well-formed JSON data. With the widespread use of JQuery it might be a mark of recognition for their work. Unfortunately, it can not be customised in JQuery, we checked that already…one has to change the source code which is not really feasible.
>
> As mentioned before I’am surprised that JQuery does not support other encoding then the "x-www-form-urlencode standard” ;o(
Re: Kendo UI and $filter encoding
Posted by "Bolz, Michael" <mi...@sap.com>.
Hi Ronny,
> I fully understand, that OLingo is following the standard, however, would it make sense to introduce a parameter to turn on or off support for the “+” separator in the library?
I see the benefit to support such additional convenience, but in a core library for a specification it is no “must be” (IMHO).
My suggestion is to create an according issue [1] and ideally attach a solution based on your suggestion with the “additional parameter”.
I can not promise that this will get in the next release, however I will take a look into it.
Best Regards,
Michael
[1]: https://issues.apache.org/jira/browse/OLINGO
> A bit along the line of the GSon Parameter to “try to support” not-well-formed JSON data. With the widespread use of JQuery it might be a mark of recognition for their work. Unfortunately, it can not be customised in JQuery, we checked that already…one has to change the source code which is not really feasible.
As mentioned before I’am surprised that JQuery does not support other encoding then the "x-www-form-urlencode standard” ;o(
>
> As Ramesh also mentioned, any developer using URLEncoder.encode() in Java will automatically use the x-www-form-urlencode standard. Many wouldn't even know the issue before they run into it.
>
> Yours,
>
> Ronny
>
>
>> On 07 Aug 2015, at 14:56, Bolz, Michael <michael.bolz@sap.com <ma...@sap.com>> wrote:
>>
>> Hi Ronny,
>>
>> I took a look into URI Conventions for OData V2 [1] (http://www.odata.org/documentation/odata-version-2-0/uri-conventions#UriEquivalence <http://www.odata.org/documentation/odata-version-2-0/uri-conventions#UriEquivalence>).
>> There is recommended that *each URI SHOULD be normalized using the rules specified in RFC3986
>> and in RFC3986 - Section 2 [2] only *percent encoding* is listed.
>> Based on that Olingo only supports percent encoding of the URL.
>>
>> Btw, I’am surprised that JQuery does the encoding in "application/x-www-form-urlencoded” type.
>> Is it not possible to configure how JQuery encodes the request url?
>>
>> Best regards,
>> Michael
>>
>> [1]: http://www.odata.org/documentation/odata-version-2-0/uri-conventions#UriEquivalence <http://www.odata.org/documentation/odata-version-2-0/uri-conventions#UriEquivalence>
>> [2]: http://tools.ietf.org/html/rfc3986#section-2 <http://tools.ietf.org/html/rfc3986#section-2>
>>
>>> On 07 Aug 2015, at 13:49, Ronny Bremer <rbremer@almanid.com <ma...@almanid.com>> wrote:
>>>
>>> We are currently in a ping pong email thread with the support guys from Telerik about an issue, which I need to ask the Olingo experts about.
>>>
>>> Kendo UI is being used as an OData consumer, version 2 of the standard. When Kendo UI generates a $filter query URL (they actually let JQuery handle this) it will look like this:
>>>
>>> http://xxx.com/OData.svc/Cars&$filter=Name <http://xxx.com/OData.svc/Cars&$filter=Name> eq ‘YYyy’
>>>
>>> So far it looks good, however, this is what will end up on the wire:
>>>
>>> http://xxx.com/OData.svc/Cars&%27filter=Name+eq+%24YYyy%24 <http://xxx.com/OData.svc/Cars&%27filter=Name+eq+%24YYyy%24>
>>>
>>> Now Olingo has a problem decoding that and throws an InvalidFilter exception. The reason is the “+” sign as a separator between the filter items. If I replace them manually with %20 everything works as expected.
>>>
>>> I did check the OData specification, unfortunately they only show the filter URL before the encoding. According the the HTTP Standard the www-url-encoding for HTML forms (!) replaces a space with a “+” in the URL, but I fail to see why an OData query should be encoded like a HTTP form.
>>>
>>> Telerik refers to the HTTP standard specification 4.0.1, where a “+” is the legal substitute for spaces. Is that really the case? I am not sure.
>>> So my question is, is Telerik right with its interpretation and therefore Olingo makes a mistake or is the “+” sign really is an invalid character in the URL?
>>>
>>> Well, in case Olingo handles it incorrectly, what would be the best way to fix it? :)
>>>
>>> Thank you for your time,
>>>
>>> Ronny
>>>
>>
>
Re: Kendo UI and $filter encoding
Posted by Ronny Bremer <rb...@almanid.com>.
Hi Michael,
thats exactly what I am wondering too. JQuery is so widely used, that I wouldn’t expect it to have an oversight like that … but still, it is really hard to fully comprehend standards nowadays …
I fully understand, that OLingo is following the standard, however, would it make sense to introduce a parameter to turn on or off support for the “+” separator in the library? A bit along the line of the GSon Parameter to “try to support” not-well-formed JSON data. With the widespread use of JQuery it might be a mark of recognition for their work. Unfortunately, it can not be customised in JQuery, we checked that already…one has to change the source code which is not really feasible.
As Ramesh also mentioned, any developer using URLEncoder.encode() in Java will automatically use the x-www-form-urlencode standard. Many wouldn't even know the issue before they run into it.
Yours,
Ronny
> On 07 Aug 2015, at 14:56, Bolz, Michael <mi...@sap.com> wrote:
>
> Hi Ronny,
>
> I took a look into URI Conventions for OData V2 [1] (http://www.odata.org/documentation/odata-version-2-0/uri-conventions#UriEquivalence <http://www.odata.org/documentation/odata-version-2-0/uri-conventions#UriEquivalence>).
> There is recommended that *each URI SHOULD be normalized using the rules specified in RFC3986
> and in RFC3986 - Section 2 [2] only *percent encoding* is listed.
> Based on that Olingo only supports percent encoding of the URL.
>
> Btw, I’am surprised that JQuery does the encoding in "application/x-www-form-urlencoded” type.
> Is it not possible to configure how JQuery encodes the request url?
>
> Best regards,
> Michael
>
> [1]: http://www.odata.org/documentation/odata-version-2-0/uri-conventions#UriEquivalence <http://www.odata.org/documentation/odata-version-2-0/uri-conventions#UriEquivalence>
> [2]: http://tools.ietf.org/html/rfc3986#section-2 <http://tools.ietf.org/html/rfc3986#section-2>
>
>> On 07 Aug 2015, at 13:49, Ronny Bremer <rbremer@almanid.com <ma...@almanid.com>> wrote:
>>
>> We are currently in a ping pong email thread with the support guys from Telerik about an issue, which I need to ask the Olingo experts about.
>>
>> Kendo UI is being used as an OData consumer, version 2 of the standard. When Kendo UI generates a $filter query URL (they actually let JQuery handle this) it will look like this:
>>
>> http://xxx.com/OData.svc/Cars&$filter=Name <http://xxx.com/OData.svc/Cars&$filter=Name> eq ‘YYyy’
>>
>> So far it looks good, however, this is what will end up on the wire:
>>
>> http://xxx.com/OData.svc/Cars&%27filter=Name+eq+%24YYyy%24 <http://xxx.com/OData.svc/Cars&%27filter=Name+eq+%24YYyy%24>
>>
>> Now Olingo has a problem decoding that and throws an InvalidFilter exception. The reason is the “+” sign as a separator between the filter items. If I replace them manually with %20 everything works as expected.
>>
>> I did check the OData specification, unfortunately they only show the filter URL before the encoding. According the the HTTP Standard the www-url-encoding for HTML forms (!) replaces a space with a “+” in the URL, but I fail to see why an OData query should be encoded like a HTTP form.
>>
>> Telerik refers to the HTTP standard specification 4.0.1, where a “+” is the legal substitute for spaces. Is that really the case? I am not sure.
>> So my question is, is Telerik right with its interpretation and therefore Olingo makes a mistake or is the “+” sign really is an invalid character in the URL?
>>
>> Well, in case Olingo handles it incorrectly, what would be the best way to fix it? :)
>>
>> Thank you for your time,
>>
>> Ronny
>>
>
Re: Kendo UI and $filter encoding
Posted by Ramesh Reddy <ra...@redhat.com>.
I have run into same issue sometime ago in a unit test, I believe I was using the URLEncode for that, so it was easy enough to fix for that case. Since clients can use different strategies to encode it may be worth to recognize + encoding in the Olingo
----- Original Message -----
> Hi Ronny,
> I took a look into URI Conventions for OData V2 [1] (
> http://www.odata.org/documentation/odata-version-2-0/uri-conventions#UriEquivalence
> ).
> There is recommended that *each URI SHOULD be normalized using the rules
> specified in RFC3986
> and in RFC3986 - Section 2 [2] only *percent encoding* is listed.
> Based on that Olingo only supports percent encoding of the URL.
> Btw, I’am surprised that JQuery does the encoding in
> "application/x-www-form-urlencoded” type.
> Is it not possible to configure how JQuery encodes the request url?
> Best regards,
> Michael
> [1]:
> http://www.odata.org/documentation/odata-version-2-0/uri-conventions#UriEquivalence
> [2]: http://tools.ietf.org/html/rfc3986#section-2
> > On 07 Aug 2015, at 13:49, Ronny Bremer < rbremer@almanid.com > wrote:
>
> > We are currently in a ping pong email thread with the support guys from
> > Telerik about an issue, which I need to ask the Olingo experts about.
>
> > Kendo UI is being used as an OData consumer, version 2 of the standard.
> > When
> > Kendo UI generates a $filter query URL (they actually let JQuery handle
> > this) it will look like this:
>
> > http://xxx.com/OData.svc/Cars&$filter=Name eq ‘YYyy’
>
> > So far it looks good, however, this is what will end up on the wire:
>
> > http://xxx.com/OData.svc/Cars&%27filter=Name+eq+%24YYyy%24
>
> > Now Olingo has a problem decoding that and throws an InvalidFilter
> > exception.
> > The reason is the “+” sign as a separator between the filter items. If I
> > replace them manually with %20 everything works as expected.
>
> > I did check the OData specification, unfortunately they only show the
> > filter
> > URL before the encoding. According the the HTTP Standard the
> > www-url-encoding for HTML forms (!) replaces a space with a “+” in the URL,
> > but I fail to see why an OData query should be encoded like a HTTP form.
>
> > Telerik refers to the HTTP standard specification 4.0.1, where a “+” is the
> > legal substitute for spaces. Is that really the case? I am not sure.
>
> > So my question is, is Telerik right with its interpretation and therefore
> > Olingo makes a mistake or is the “+” sign really is an invalid character in
> > the URL?
>
> > Well, in case Olingo handles it incorrectly, what would be the best way to
> > fix it? :)
>
> > Thank you for your time,
>
> > Ronny
>
Re: Kendo UI and $filter encoding
Posted by "Bolz, Michael" <mi...@sap.com>.
Hi Ronny,
I took a look into URI Conventions for OData V2 [1] (http://www.odata.org/documentation/odata-version-2-0/uri-conventions#UriEquivalence <http://www.odata.org/documentation/odata-version-2-0/uri-conventions#UriEquivalence>).
There is recommended that *each URI SHOULD be normalized using the rules specified in RFC3986
and in RFC3986 - Section 2 [2] only *percent encoding* is listed.
Based on that Olingo only supports percent encoding of the URL.
Btw, I’am surprised that JQuery does the encoding in "application/x-www-form-urlencoded” type.
Is it not possible to configure how JQuery encodes the request url?
Best regards,
Michael
[1]: http://www.odata.org/documentation/odata-version-2-0/uri-conventions#UriEquivalence <http://www.odata.org/documentation/odata-version-2-0/uri-conventions#UriEquivalence>
[2]: http://tools.ietf.org/html/rfc3986#section-2 <http://tools.ietf.org/html/rfc3986#section-2>
> On 07 Aug 2015, at 13:49, Ronny Bremer <rb...@almanid.com> wrote:
>
> We are currently in a ping pong email thread with the support guys from Telerik about an issue, which I need to ask the Olingo experts about.
>
> Kendo UI is being used as an OData consumer, version 2 of the standard. When Kendo UI generates a $filter query URL (they actually let JQuery handle this) it will look like this:
>
> http://xxx.com/OData.svc/Cars&$filter=Name eq ‘YYyy’
>
> So far it looks good, however, this is what will end up on the wire:
>
> http://xxx.com/OData.svc/Cars&%27filter=Name+eq+%24YYyy%24
>
> Now Olingo has a problem decoding that and throws an InvalidFilter exception. The reason is the “+” sign as a separator between the filter items. If I replace them manually with %20 everything works as expected.
>
> I did check the OData specification, unfortunately they only show the filter URL before the encoding. According the the HTTP Standard the www-url-encoding for HTML forms (!) replaces a space with a “+” in the URL, but I fail to see why an OData query should be encoded like a HTTP form.
>
> Telerik refers to the HTTP standard specification 4.0.1, where a “+” is the legal substitute for spaces. Is that really the case? I am not sure.
> So my question is, is Telerik right with its interpretation and therefore Olingo makes a mistake or is the “+” sign really is an invalid character in the URL?
>
> Well, in case Olingo handles it incorrectly, what would be the best way to fix it? :)
>
> Thank you for your time,
>
> Ronny
>