limit size of X-Druid-Response-Context header to 7K

[himanshug]

fixes #2331

[gianm]

The limit is probably on the bytes rather than chars so I think it would be better to writeValueAsBytes

[himanshug]

header bytes are encoded using ASCII, so 1 char = 1 byte
in the builder.header(String key, Object value), eventually somewhere value.toString() is called and encoded using ASCII . I tried passing a byte[] to builder.header(..) and in response I got [B@468a1ce3.
I have updated the comment.

[drcrallen]

StringUtils.toUtf8(responseCtxString).length might not equal responseCtxString.length()

[drcrallen]

what happens in utf8 multi-byte characters in headers?

[himanshug]

@drcrallen jetty would do a buffer.put((byte)(0xff&c)); see https://github.com/eclipse/jetty.project/blob/master/jetty-http/src/main/java/org/eclipse/jetty/http/HttpGenerator.java#L963

[xvrl]

@drcrallen @himanshug the most correct way would be to enable the JsonGenerator .Feature.ESCAPE_NON_ASCII feature in jackson to ensure we correctly escape all non-ascii characters, otherwise the resulting context may not be valid JSON.

[himanshug]

@xvrl i guess if we are worried about invalid json in the header, then we should really move towards having a first class "metadata" attribute in the query response payload and put the information there. header is not probably the right place as you are going to remove some stuff to make it valid json anyway.

[xvrl]

@himanshug added a few more comments that got buried in the rebase, in case you don't see them.

#2336 (comment)
#2336 (comment)
#2336 (comment)

[fjy]

👍

[xvrl]

@himanshug we don't have to get held up by the non-ascii stuff, but I feel having a header that might either be incomplete or mangled will have to be addressed at some point.

+1 once we file an issue about the non-ascii mangling in reponse context

[himanshug]

@xvrl tracking in #2372