-
Notifications
You must be signed in to change notification settings - Fork 55
Description
Playing around with the mqtt chat example (https://github.com/jolie/jolie-mosquitto/tree/master/Jolie/example/chat) I have managed to identify a very subtle bug which manifests after doing the HTTP refactoring (including concurrent message dispatching) last year.
leonardo.ol (static HTTP server) gets aggregated with the embedded service Frontend which provides some endpoints to fetch MQ messages. Those are used by the client's UI frontend to get the updates.
inputPort HTTPInput {
Protocol: http {
...
}
Location: "auto:ini:/Locations/Leonardo:file:locations.ini"
Interfaces: HTTPInterface
Aggregates: Frontend
}
A curl fetch operation with the content type JSON returns the data in XML:
curl --verbose -XPOST http://localhost:16000/getChatMessages -H"Accept: application/json" -H"Content-Type: application/json"
> POST /getChatMessages HTTP/1.1
> Host: localhost:16000
> User-Agent: curl/7.81.0
> Accept: application/json
> Content-Type: application/json
< HTTP/1.1 200 OK
< Server: Jolie
< Connection: close
< X-Jolie-Operation: getChatMessages
< X-Jolie-ServicePath: /
< Content-Type: text/xml; charset=utf-8
< Content-Length: 26
<getChatMessagesResponse/>
When exposing Frontend as a separate endpoint (= HTTP input port) everything is ok:
curl --verbose -XPOST http://localhost:16000/getChatMessages -H"Accept: application/json" -H"Content-Type: application/json"
> POST /getChatMessages HTTP/1.1
> Host: localhost:16000
> User-Agent: curl/7.81.0
> Accept: application/json
> Content-Type: application/json
< HTTP/1.1 200 OK
< Server: Jolie
< X-Jolie-Operation: getChatMessages
< X-Jolie-ServicePath: /
< Content-Type: application/json; charset=utf-8
< Content-Length: 2
{}
It seems that the Accept header information gets lost when using service aggregation, so Jolie picks the default for structured data (XML).
@fmontesi do you have any clue why this could be the case?