HttpRequest._stream

[django]

HttpRequest._stream

[vikrantpogula]

Even i run into the same issue when using rest framework along with the websocket

[andrewgodwin]

Yeah, I'm looking into an emulation layer to prevent this; hopefully I can provide a StringIO object with the right information for DRF.

[vikrantpogula]

@andrewgodwin Hey, any update on this ? I'd be happy to help in anyway if there's something I can do !

[andrewgodwin]

Well, I just finished finalising how to transmit request bodies in ASGI, which was the underlying blocker - there's no way to provide the body emulation otherwise. Now that's done, fixing up the Request object to actually take those bodies is next, followed by things like this that are emulation layers.

You can take a stab if you like, but I have it half-written already, just need to get it done and tested :) What would be useful is if you could work out what DRF is trying to use _stream for; I'd like to make sure it's just trying to access the raw request body.

[vikrantpogula]

@andrewgodwin OK! Ive just read the ASGI spec and understand what you exactly mean. I will take a stab into DR..

[vikrantpogula]

@andrewgodwin i've been playing around with channels last couple of days, really great work, thanks !

regarding the _stream issue, it does not exist when using separate servers (ie not using --accept-all) for HTTP and WS. Everything seems to work as intended.

PS : I've seen you have changed the current 0.8 approach and are now using andrewgodwin/daphne as the server. 👍

[andrewgodwin]

Yup - running WSGI and WS seperately will always be an option, as WSGI is just more mature and stable and it's silly not letting you use it (and likely slightly more efficient as it's not double-transforming requests).

Only downside is that it means no simultaneous websocket support - you have to tell your webserver to route a prefix - but that's not the worst thing. I'll be adding some diagrams into the real docs about this to show the different options.

[vikrantpogula]

@andrewgodwin just posting an update here. I was previously wrong, everything is not working as intended, but I have better info:

• DRF tries to access _stream while trying to parse request bodies (POST/DELETE requests)
• Even if the request does have a body - error is not raised till you access request.data

TL:DR from my testing (v0.8)

Works
  - request.META
  - headers
  - query_params

Doesn't Work
 - request.data

[andrewgodwin]

Yes, I suspect that I need to implement read() and other methods on the new WsgiRequest class.

[DanLipsitt]

Is it possible to implement this as a patch against v0.8, or does it have to wait for ASGI to settle down in the master branch? I'm trying to use channels with DRF right now.

I'll take a look and try to at least develop a failing test. I don't know if I'll be able to do more than that, or if it makes sense to.

[andrewgodwin]

Nah, 0.8 doesn't have HTTP body transport at all. Once I get some time I should be able to get a 0.9 out; ASGI is pretty settled already and seems to work alright in practice, just needs a bit of polish so it's useable out of the box.

[DanLipsitt]

Do you have a sense of when that might be? Not trying to push. 😉

[andrewgodwin]

Afraid I can't commit to dates; I'm not working on this in a paid capacity yet, so it's all personal time as and when it comes up.

[DanLipsitt]

A comment on django.http.request.HttpRequest.read() says

# File-like and iterator interface.
#
# Expects self._stream to be set to an appropriate source of bytes by
# a corresponding request subclass (e.g. WSGIRequest).
# Also when request data has already been read by request.POST or
# request.body, self._stream points to a BytesIO instance
# containing that data.

It looks to me like setting self._stream = BytesIO(self._body) in AsgiRequest.__init__() might satisfy that?

[andrewgodwin]

Yup, that's the plan. Just need to make sure the whole thing works end-to-end properly and correctly encodes/decodes; it's all still slightly experimental.

[andrewgodwin]

OK, stream is now implemented.