Description
What is the bug?
From the OTLP spec:
The server MUST set “Content-Type: application/x-protobuf” header if the response body is binary-encoded Protobuf payload. The server MUST set “Content-Type: application/json” if the response is JSON-encoded Protobuf payload. The server MUST use the same “Content-Type” in the response as it received in the request.
Currently the the response format does not change depending on request format.
No content-type and a blank response is returned for success, and Content-Type: application/octet-stream + binary-encoded proto for errors:
Line 342 in ba300f5
JSON requests should have Content-Type: application/json set in responses, with the responses following the JSON protobuf encoding, while protobuf requests should have Content-Type: application/x-protobuf set in responses (for the protobuf error case, the response body is fine but the Content-Type should be set correctly)
How to reproduce it?
A request like
curl -i -XPOST -H 'Content-Type: application/json' <mimir endpoint> -d '{
"resourceMetrics": [
{
"scopeMetrics": [
{
"metrics": [
{
"name": "test_metric",
"unit": "s",
"description": "",
"gauge": {
"dataPoints": [
{
"asInt": 1,
"timeUnixNano": 1741602284008000000,
"attributes": [
{
"key": "bar_label",
"value": {
"stringValue": "abc"
}
}
]
}
]
}
}
]
}
]
}
]
}'
returns a 200 success without a content-type. For a valid json response {} should be returned. Similar issues apply to the other response combinations (success/error + request format)
What did you think would happen?
A response with Content-Type: application/json and body {}
What was your environment?
Issue can be seen in the current code (main currently at commit 20548c3)
Any additional context to share?
No response