Should Deprecation HTTP headers normalize comma in messages

[Mpdreamz]

Not entirely sure what the HTTP spec status of response headers is but with request headers

Key: Value1, Value2

is equivalent to:

Key: Value1
Key: Value2

Quite a few deprecation messages contain a comma which causes an ambiguity when I get to actually parse these (from .NET BCL in this case.

e.g:

HTTP/1.1 200 OK
Warning: Deprecated field [fielddata_fields] used, expected [docvalue_fields] instead
Warning: [groovy] scripts are deprecated, use [painless] scripts instead
content-type: application/json; charset=UTF-8
content-length: 3676

Yields:

Which is impossible to stitch back together as two messages.

[nik9000]

Bleh. Looks like we shouldn't use comma, yeah. This SO question has some fun discussion about it. It looks like a lot of standard headers contain , and can't be merged, but well behaved headers don't contain ,. It links to this (MPLed) code that shows how a browser does it....

[jasontedor]

It is indeed the case that the warning header can be multi-valued which means that we do need to address the comma-separated issue here. On closer inspection of the HTTP spec, we are not following the warning header specification. We should be prepending each warning with a code (we can just use 199 miscellaneous) and an agent (we can just use the Elasticsearch version), and then we should be quoting each warning string to address the comma issue.