Eventstore: Empty content-type when (n)acking messages

[pkruithof]

When I send a POST request to ack or nack a message, the response has an empty Content-Type header. Not sure if it goes against the HTTP spec, but I think this header needs to be fixed here.

Anonymized IP:

/app # curl -v -XPOST -H 'Content-Type: application/json' -H 'Content-Length: 0' 'http://event-store:2113/subscription
s/stream/subscription/nack/8c80f1f3-e8c1-4251-a27f-6793c8ab00a5?action=retry'
*   Trying <ip>...
* TCP_NODELAY set
* Connected to component-event-store (<ip>) port 2113 (#0)
> POST /subscriptions/stream/subscription/nack/8c80f1f3-e8c1-4251-a27f-6793c8ab00a5?action=retry HTTP/1.1
> Host: component-event-store:2113
> User-Agent: curl/7.60.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 0
> 
< HTTP/1.1 202 
< Access-Control-Allow-Methods: POST, OPTIONS
< Access-Control-Allow-Headers: Content-Type, X-Requested-With, X-Forwarded-Host, X-Forwarded-Prefix, X-PINGOTHER, Authorization, ES-LongPoll, ES-ExpectedVersion, ES-EventId, ES-EventType, ES-RequiresMaster, ES-HardDelete, ES-ResolveLinkTos
< Access-Control-Allow-Origin: *
< Access-Control-Expose-Headers: Location, ES-Position, ES-CurrentVersion
< Content-Type: 
< Server: Mono-HTTPAPI/1.0
< Date: Thu, 21 Jun 2018 14:19:10 GMT
< Content-Length: 0
< Keep-Alive: timeout=15,max=100

[gregoryyoung]

Hmm there is no content. What should the content be in your opinion?

[pkruithof]

Good question, if there's no content, should there even be a Content-Type header?

[gregoryyoung]

If we were to argue specification-wise I would say its fine but can understand the concerns. What would be your ideal handling of this case?

[pkruithof]

I've read parts of the spec but I'm hesitant to say whether it should be included in this case, or not. I actually don't mind either way. The main reason I came across this is because the http library I'm using broke because of it.

Since there's no content, an application/json type would actually be incorrect, because it cannot be decoded. text/plain could be applied, but seems wrong when there's no content.

Two suggestions:

1. Remove the Content-Type header altogether
2. Give the response a body, which "should" be included, according to the spec:

The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.

What do you think?

[jen20]

My reading of the specification (section 7.2.1) is that we should likely remove the Content-Type header here.

Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body.