Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chunk large request bodies into multiple http.request.body events #126

Closed
michalmo opened this issue Jul 12, 2017 · 8 comments · Fixed by #335
Closed

Chunk large request bodies into multiple http.request.body events #126

michalmo opened this issue Jul 12, 2017 · 8 comments · Fixed by #335

Comments

@michalmo
Copy link

I've been searching through the code and Channels seems to support reading chunked bodies, but Daphne always sends the whole body in the http.request message.
Am i missing something?

@JohnDoee
Copy link
Contributor

You seem to be correct and you can probably turn this ticket into a feature request instead.

@proofit404
Copy link
Member

Yes, you're correct. Daphne doesn't support bodies chunking at this time.

@michalmo michalmo changed the title daphne doesn't support body chunking? add for support body chunking Jul 12, 2017
@andrewgodwin
Copy link
Member

Yup, tagged it as an enhancement. This will probably get a lot easier with the changes I'm proposing to Channels in the near future (http://www.aeracode.org/2017/7/11/towards-channels-20/), so it's likely we'll wait till then to implement it as it'll perform much better.

@michalmo michalmo changed the title add for support body chunking add support for body chunking Jul 12, 2017
@michalmo
Copy link
Author

Thanks, interesting read.

@andrewgodwin andrewgodwin changed the title add support for body chunking Chunk large request bodies into multiple http.request.body events Feb 2, 2018
@andrewgodwin
Copy link
Member

Just to reconfirm that Daphne 2.0 still does not support chunking incoming HTTP bodies, though it's less of a problem as it's now an in-memory dict that gets passed around rather than going over a channel layer. It should still be fixed to read from the client socket progressively, though.

@Boryotto
Copy link

I've encountered this problem lately and I would like to try and solve this issue. Would you say this is currently solvable? Are there any new insights about this issue?

@andrewgodwin
Copy link
Member

It's solvable, but might already be solved in uvicorn if you need it now? I haven't checked recently.

@JJK-IO
Copy link

JJK-IO commented Mar 3, 2019

Alternatively as the docs in Channels mentions you can route traffic based on traffic type using NGINX. If you need this up and running for production sites you can route similar to this.

https://serverfault.com/questions/910805/proxy-websockets-and-http-through-the-same-location-in-nginx

Requirements:
Run a daphne server on port 8000
Run a gunicorn server on port 8001

map $http_upgrade $type {
  default "web";
  websocket "ws";
}

upstream daphne {
  server: localhost:8000;
}

upstream gunicorn {
  server: localhost:8001;
}

server {
  # ...

  location / {
    try_files /nonexistent @$type;
  }

  location @ws {
    ...
    proxy_pass: http://daphne;
  }

  location @web {
    ...
    proxy_pass: http://gunicorn;
  }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants