Ignore media ranges when parsing #64721
Conversation
Browsers are sending media ranges with quality factors on Accept header. We should ignore the value and responde with applicaiton/json closes elastic#64689 relates elastic#51816
|
Pinging @elastic/es-core-infra (:Core/Infra/REST API) |
original-brownbear
left a comment
original-brownbear
left a comment
There was a problem hiding this comment.
LGTM as a workaround thanks!
| if (headerValue != null) { | ||
| if (isMediaRange(headerValue) || "*/*".equals(headerValue)) { | ||
| return null; | ||
| } |
There was a problem hiding this comment.
I think this should be moved down to and checked against elements[0] instead of the whole headerValue. A parameter could have a comma. Probably not..but slightly more correct.
There was a problem hiding this comment.
If we check for element[0] we could not check against something like text/HTML;q=0, application/json
Media range is a coma separated list where each media type can have a list of parameters after semicolon .
Comma (delimiters at all) are not allowed within media type name or parameters
There was a problem hiding this comment.
OK ..that makes sense. sorry for the noise.
however...minor clarification your values for the parameters may be quoted which can contain any ASCII char accept-extension = ";" token [ "=" ( token | quoted-string ) ] however, this is very unlikely to encounter a comma there
There was a problem hiding this comment.
ah.. you are totally right. I did not look into quoted string part. Indeed this can contain a comma.
And CVS could be a media type that would like to have it.
we don't support that at the moment, but at some point I think it would make sense that we do.
jakelandis
left a comment
jakelandis
left a comment
There was a problem hiding this comment.
One suggestion to move the check down a line. This is a good workaround, however long term we should probably consider supporting some simple form of content negotiation.
4 participants
Browsers are sending media ranges with quality factors on Accept header.
We should ignore the value and respond with applicaiton/json
closes #64689
relates #51816
gradle check?