CODEWITHSUNDEEP
pythonhttpnginxuwsgichunked-encoding
user3490695
user3490695

Reputation: 147

uwsgi/nginx configuration for chunked response

I have two endpoints like below:

GET on /api/v1/foo

POST on /api/v1/foo

I need the POST implementation to send back chunked responses using HTTP/1.1 chuked-tranfer encoding however the GET endpoint should send plain JSON

My setup is nginx -> uwsgi -> flask.

I see some of my chunks currently getting truncated at a hex size of 1000 which is 4K in bytes and not the same as my flask layer sent it. Probably because I'm missing some nginx or uwsgi configuration.

uwsgi configuration(uwsgi.ini):

[uwsgi]
route = ^/api/v1/foo$ goto:dochunked
route-run = last:

route-label = dochunked
route-if = equal:$\{REQUEST_METHOD\};POST goto:dopostchunked
route-run = last:

route-label = dopostchunked
route-run = chunked:

nginx configuration:

location / {
    uwsgi_pass unix:var/uwsgi.sock;
    uwsgi_read_timeout 600; 
    include uwsgi_params;   
}

location /api/v1/foo {   
    uwsgi_pass unix:var/uwsgi.sock;
    uwsgi_read_timeout 600; 
    include uwsgi_params;   

    if ($request_method = "POST" ) {
        set $chunked_transfer_encoding on;
        add_header X-Accel-Buffering no;
    }
}

curl response headers

HTTP/1.1 200 OK
Server: nginx/1.10.1
Date: Wed, 03 Jan 2018 00:06:50 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
Connection: keep-alive
X-Frame-Options: deny
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Accel-Buffering: no

Upvotes: 3

Views: 3927

Answers (1)

regilero
regilero

Reputation: 30496

Chunking is about Transfer-Encoding, plain JSON is Content-Type, the two things are not related.

The transfer encoding stuff is just about the communication methods used by the two HTTP 1.1 endpoints (the server and the client). Like would be a gzip compression, also. Using chunked transmission avoids using the Content-Length headers and allows the response to be sent in multiple chunks, of course. But on the other side, once the response is received chunks are added, and you should not see any difference between a response sent via Content-Length+big-body-in-one-chunk or a body-sent-in-multiple-chunks.

I say should because you may experience problems with bad HTTP/1.1. libraries which do not wait until the end of the message (last chunk marker) before launching something like an response-receveid event for application languages.

Usually using chunks or not is the responsability of the HTTP server, and you have few contgrol other that because chunks support is a requested feature of HTTP/1.1. Playing with the size of the response body and the size of buffers used by the http server you may see differences on the way chunks are made. If you have multiple actors in the chain (like here flask and Nginx), each actor can decide to reorganize the chunks, merge some of them (buffering), or not.

But as I said, you should not care about it. Unless your client side of the application as bugs with chunked encoding, that would mean your side of the HTTP communication doesn't understand HTTP/1.1.

Finally, if you really need to avoid chunks, but you shouldn't, I see 3 options:

  • You could enforce an HTTP/1.0 response. No chunks with HTTP/1.0. But that's a very very old version of the protocol. To do that you'll have to ask for HTTP/1.0 in the request side, you'll get an HTTP/1.1 response from Nginx but without the advanced features of HTTP/1.1 (like chunks).
  • You could use the nginx chunked_transfer_encoding setting. we can see it's on by default, so usually you use that to set it to off on a specific location. Your current way of using it does nothing. This option was made specifically for bad HTTp clients, as stated:

    It may come in handy when using a software failing to support chunked encoding despite the standard’s requirement.

  • You could maybe also try playing with proxy_buffering off, that may work, I'm unsure.

Upvotes: 3

Related Questions