Client should verify response content-type #679
Conversation
| @@ -511,6 +511,21 @@ func (cc *connectUnaryClientConn) validateResponse(response *http.Response) *Err | |||
| } | |||
| cc.responseTrailer[strings.TrimPrefix(k, connectUnaryTrailerPrefix)] = v | |||
| } | |||
| err := connectValidateUnaryResponseContentType( | |||
There was a problem hiding this comment.
Could this be moved into the validate response function?
There was a problem hiding this comment.
It is. Do you mean inlined? I had made it a separate function to make it easier to test.
There was a problem hiding this comment.
Sorry misread, thought the method on the duplexcall was due to it not being part of this function, but thats for the request params.
| response.Status, | ||
| getHeaderCanonical(response.Header, headerContentType), | ||
| ) | ||
| if err != nil { |
There was a problem hiding this comment.
Can we scope err to the if block? It's visually a little ugly, but the functions in this portion of the code are long enough that I'd love to minimize scope where possible. Same below.
There was a problem hiding this comment.
I had not done so just because I find it a bit hard to read when the if keyword is far from the actual condition. But if that's accepted style, and even preferred in this case, I'll change it.
This also formats the grpc version of the check so it is consistent with the other two. Addresses comment in prior PR: #679 (comment)
@smaye81 found some more bugs with new conformance test cases.
The client is not verifying that the response has the correct content-type. So this change adds that verification.
Some tests, that had simple handlers that weren't setting a valid content-type, had to be updated. Sorry for the large diff stats, but it's not as bad as it looks. This PR adds three new table-driven tests that account for 75% of the lines of code.