The following URI triggered an error in the public OData service:
http://services.odata.org/V4/Northwind/Northwind.svc/Suppliers?$filter=Address eq '<A'
Entity type Supplier contains property Address of type Edm.String. So, the value of Address may contain any UTF-8 character from the definition (see section 6. Primitive data types).
The server responds with:
Runtime Error: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons).
Is the there something wrong with this URI or it is really a problem on the server side (e.g. inappropriate parsing of the $filter query option)?
You should encode your query URL, e.g. with help of
http://prasannaadavi.com/2014/06/handling-special-characters-in-odata-queries.html
How are special characters handled in an oData query?
In your special case you should try encoding "<A" with "<A"
--> found in https://web.archive.org/web/20150101222238/http://msdn.microsoft.com/en-us/library/aa226544(SQL.80).aspx)
Related
I need help showing the data from my own remote server with oDATA.
When I want to show the data in the view, I get the following error
invalid MIME part type.
These are the Captures of Error
my https://******/$metadata?
My Table control from SApui5 Course App example
Error when executing the application
And Console error
When I insert this.getModel().setUseBatch(false) in the init : function () of the Component.js, it does not give me the error, nor in the console, but it does not show me the records either .. Can someone give me an idea?
It's an old question, but recently I've got the same error with batch request processing and in my case the root cause was that when building batch processing response with content type multipart/mixed you have to use CRLF as a text line separator ('\r\n') and not only '\n'. See also here in multipart response specification. The hard part was that correct and incorrect responses look absolutely identical when debugging.
I have problem querying for "#microsoft.graph.downloadUrl" using microsoft graph endpoint.
Running a query like this:
https://graph.microsoft.com/v1.0/me/drive/root/children?$select=id,name,file,folder,size,lastModifiedDateTime,#microsoft.graph.downloadUrl
Returns a bad request error with message: "Syntax error: character '#' is not valid at position..." I had not such a problem with OneDrive direct endpoint so I am wondering how exactly should I run the intended query?
Earlier this year the attribute #content.downloadUrl was renamed to #microsoft.graph.downloadUrl.It looks like there is an issue/discrepancy between the attribute's name in the results verse the query parameters.
The $select clause is still looking for the original name. As best I can tell, this isn't documented at the moment. That said, this query should do the trick for you:
/me/drive/root/children?$select=id,name,file,folder,size,lastModifiedDateTime,content.downloadUrl
When sending a request via Zuul to a client, Zuul seems to change the query String. More specifically, if the client should receive an url-encoded query String, Zuul decodes the query String once. Here is a concrete example:
If "http://localhost:8080/demo/demo?a=http%3A%2F%2Fsomething/" is sent to the client, the client receives as a query String "a=http://something/".
Looking into Zuul`s code, the function "buildZuulRequestQueryParams" uses "HTTPRequestUtils.getInstance().getQueryParams();" which decodes the query String.
Is this a desired feature or a bug?
Zuul actually offers a flag to disable this behavior.
8.9 Query String Encoding
When processing the incoming request, query params are decoded so that they can be available for possible modifications in Zuul filters. They are then re-encoded the backend request is rebuilt in the route filters. The result can be different than the original input if (for example) it was encoded with Javascript’s encodeURIComponent() method. While this causes no issues in most cases, some web servers can be picky with the encoding of complex query string.
To force the original encoding of the query string, it is possible to pass a special flag to ZuulProperties so that the query string is taken as is with the HttpServletRequest::getQueryString method, as shown in the following example:
application.yml.
zuul:
forceOriginalQueryStringEncoding: true
[Note] This special flag works only with SimpleHostRoutingFilter.
Also, you loose the ability to easily override query parameters with
RequestContext.getCurrentContext().setRequestQueryParams(someOverriddenParameters),
because the query string is now fetched directly on the original
HttpServletRequest.
8. Router and Filter: Zuul
I was facing the same issue yesterday. I think it's related to this pull request. A faster way to solve this issue (without wait for PR get merged) is rewrite the classes in your own project using the same package and class name to override the framework class.
I ran into the same issue recently. Submitted a PR to Netflix/Zuul. Basically adding the same ability that's currently available on spring cloud gateway to Netflix. Hoping it'll get addressed soon.
If accepted, you could pretty much add a config to keep the original uri encoding
zuul.keepOriginalQueryStringEncoding=true
There was a change "3.2.10 Pruned: URI Literal suffixes for numeric types" in OData v4 specification. Now OData.Client for OData v4 sends double literals without these sfuffixes, but we need them for our proejct to work correctly. I can't find a legal way to turn back this OData v3 behaviour, except brancing OData.Client. Does anybody know a way to change this behaviour using the generated T4 client proxies or something?
It can't fallback to old numeric format (with suffix) . You may consider hooking up DataServiceContext's SendingRequest2 event, modify the request URL to meet the server side's expectation.
However, the server side should have numeric value's type information (either in model or in CLR types) just like client has for building the request, so theoretically, suffix is unnecessary.
Im getting this error:
(a:6016) The message with Action 'xxx'
cannot be processed at the receiver,
due to a ContractFilter mismatch at
the EndpointDispatcher. This may be
because of either a contract mismatch
(mismatched Actions between sender and
receiver) or a binding/security
mismatch between the sender and the
receiver. Check that sender and
receiver have the same contract and
the same binding (including security
requirements, e.g. Message, Transport,
None).
And I noticed that the binding used by my provider's WSDL is:
BasicHttpBinding_IxFlow
I guess I need to specify that in my Savon Controller. How can I do that?
Thx.
Since the error message is not really helpful (received this one for various errors) here are some suggestions:
try calling the service (or just generate the xml) from another client and record the XML
compare with Savonrb XML (it prints it to the console, not pretty formatted but good enough)
send the XML you captured from another client trough savon. Does this work? (you can specify custom XML with the block version of client#request method)
Look at (this was the problem with my service):
Order of parameters
Namespace of parameters
SOAPAction header (you can also specify it in the block version)