How to tell the HTTP server to not send chunked encoding

5
votes

I am currently writing a HTTP client to do a HTTP POST on a URL that returns a HTTP response.

However, for error messages code 400 and 500, it sends back non chunked HTTP response, and for success messages, 201, it sends a chunked response.

In the request, I am setting the content-length, so I am not sure why it is still sending us the chunked transfer encoding. Is there any other header I can set in the request, that will tell the HTTP server not to send chunked encoding?

        headerList.append("POST /v2/charges HTTP/1.1")
        headerList.append("Content-Type: application/json")
        headerList.append("host: xxxxxxxxx")
        headerList.append("request-id: ABCD001123")
        headerList.append("Content-length: %d" %len(Msg))
        hostReqHeader = "\r\n".join(headerList)
        reqData = hostReqHeader + '\r\n\r\n' + qbPosMsg

I am using sockets to send these HTTP messages, and not using httplib or requests library.

2
pythonhttphttp-headerschunked-encoding
Bad news: RFC7230, ¶4.1, "A recipient MUST be able to parse and decode the chunked transfer coding." So, there is no general standard way prevent chunked encoding. I suppose there might be a way specific to your server and outside the scope of the standard. What server are you using? – Robᵩ
See also ¶4.3, "A client MUST NOT send the chunked transfer coding name in TE; chunked is always acceptable for HTTP/1.1 recipients." – Robᵩ

2 Answers

4
votes

Chunked is a required feature of HTTP/1.1. If you do not require any other 1.1-specific features, specify HTTP/1.0 in your request:

    headerList.append("POST /v2/charges HTTP/1.0")
2
votes

The Content-Length header you are specifying in your request applies to the request, not the server's response.

Chunked transfer-encoding is never used for an HTTP request, only for a response, and only when the client specifies HTTP/1.1 as the protocol.

If your client cannot support chunked responses, simply specify HTTP/1.0 as the protocol in your request (replace HTTP/1.1 with HTTP/1.0 in your code).

There is nothing wrong with using HTTP 1.0 still. HTTP 1.0 remains quite useful for the ability to write simple clients with a few lines of code, that can still query all modern web servers. So it's quite appropriate in this situation. I think that is the beauty of HTTP, that the basic protocol is so simple. HTTP 1.1 and HTTP 2.0 add progressively more complexity in terms of being able to write a client that supports them, but all that complexity is optional - HTTP 1.0 can still be used.