You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I found an issue, that I can't solve by myself. In our setup, each request passes KONG, WILMA, and ORION-LD. If I request some entities from type Parcel in the following way: https://aaa.bbb.de/FOO/WILMA/ngsi-ld/v1/entities?type=Parcel&count=true&limit=10
with Request Header Accept: application/ld+json I expect:
an HTTP response with content-type: application/ld+json
response header value NGSILD-Results-Count: 10
but I received:
an HTTP response with content-type: application/ld+json; charset-utf-8
response header without value for NGSILD-Results-Count
If I use the same request, but the request will not pass WILMA, the HTTP response is as expected. https://aaa.bbb.de/FOO/orion-ld/ngsi-ld/v1/entities?type=Parcel&count=true&limit=10
I take a deep HTTP traffic analysis on the network layer in front of ORION-LD, but both requests arrive at ORION-LD in the same way, only the response (received by the client) is different. I investigated that issue a bit deeper with Wireshark. The orion-ld output is correct in both requests. But if the orion-ld response is forwarded to WILMA, the WILMA's output doesn't contain the NGSILD-Results-Count anymore and the content type was changed. From my point of view, WILMA interferes here destructively.
I use the docker image quay.io/fiware/pep-proxy:8.4.0
Who can handle this issue and provide a fix?
The text was updated successfully, but these errors were encountered:
Hello Jason, thanks for the fast fix.
It looks better now.
But what I found that there is a little mismatch in the Response Header attributes names:
If I request the count of entities and forward the request direct to orion-ld, the Response Header contains the attribute "NGSILD-Results-Count"
If I request the count of entities and forward the request **to WILMA first ** and then to orion-ld, the Response Header contains the attribute "ngsild-results-count"
If someone expects an attribute name with capital letters, like orion-ld sends, he will not get the result at all.
Hello lT experts,
I found an issue, that I can't solve by myself. In our setup, each request passes KONG, WILMA, and ORION-LD. If I request some entities from type Parcel in the following way:
https://aaa.bbb.de/FOO/WILMA/ngsi-ld/v1/entities?type=Parcel&count=true&limit=10
with Request Header Accept:
application/ld+json
I expect:content-type: application/ld+json
NGSILD-Results-Count: 10
but I received:
content-type: application/ld+json; charset-utf-8
If I use the same request, but the request will not pass WILMA, the HTTP response is as expected.
https://aaa.bbb.de/FOO/orion-ld/ngsi-ld/v1/entities?type=Parcel&count=true&limit=10
I take a deep HTTP traffic analysis on the network layer in front of ORION-LD, but both requests arrive at ORION-LD in the same way, only the response (received by the client) is different. I investigated that issue a bit deeper with Wireshark. The orion-ld output is correct in both requests. But if the orion-ld response is forwarded to WILMA, the WILMA's output doesn't contain the NGSILD-Results-Count anymore and the content type was changed. From my point of view, WILMA interferes here destructively.
I use the docker image
quay.io/fiware/pep-proxy:8.4.0
Who can handle this issue and provide a fix?
The text was updated successfully, but these errors were encountered: