Test the behaviour of SendURL with less-common upstreams
Two cases in particular, lacking a `Content-Type`, gave us trouble: * Transfer-Encoding: chunked * No content-type and no transfer-encoding Both of these are permitted by the HTTP RFC (cases 3 and 7), and we can talk to arbitrary HTTP servers via sendurl, so it's imperative that we handle them correctly. This commit adds tests for both cases. Responses of the latter type are transparently converted to responses of the former type. This is an automatic behaviour of the Go stdlib, which doesn't really support making the second type of response directly. Since Transfer-Encoding is a hop-by-hop header, this type of encoding is extremely common, and we're still streaming, instead of accumulating, the data, I think this is acceptable.
Showing
Please register or sign in to comment