Hi -

I'm new to WSGI and CherryPy, and I'm trying to understand why
CherryPyWSGIServer reads and discards the request body when my app first
calls write(). The code snippet that does this is footnote [1] below from
CherryPyWSGIServer (we're using 3.1.1, but the behavior looks the same in
later versions).

This is what's happening in our app, as best I can tell:
1. an unchunked request comes in with a large body and a Content-Length
header
2. my app starts reading the body from wsgi.input
3. at some arbitrary point mid-read, my app sends back a progress update to
the client via write() (which is, as far as cherrypy is concerned, just
some plain old bytes)
4. cherrypy consumes the rest of the request body as part of sending the
response headers before sending the data passed to write().

I see the rationale in the CherryPyWSGIServer code, from the HTTP 1.1 spec
-- "the server SHOULD NOT close the transport connection until it has read
the entire request" -- but I don't see how that entails reading and
discarding the request on the first write, since the connection isn't being
closed at that point. Can anyone clarify/expand?

If that rationale stands for whatever reason, how _should_ my app use
write() without discarding the remainder of the request? Do I need to make
sure the entire request body has been read before I ever call write()? Is
that a WSGI expectation?

Thanks a lot -
Yash

[1]
if (not self.close_connection) and (not self.chunked_read):
    # Read any remaining request body data on the socket.
    ...

See (especially section on .write() ) :

http://python.org/dev/peps/pep-3333/#buffering-and-streaming

Summary:

Don't use write()

Alternatives are, unfortunately, complex. I recommend to go for full-blown
generator as any in-between (inline yield's) solution will quickly become
small for you.

To simulate generator "in-line" try:

    start_response(..., ...)
    ...
    yield "snippet"
    ...
    yield "some more"
    ...
    return ['rest', 'of', 'response']

But real solution is make a looping generator class and just return it
(after start_response(... ))

I wish I could give you a simple example of smart generator, but there is
no simple example of smart generator that I know. This is relatively there:
http://jimmyg.org/blog/2009/using-yield-statements-in-wsgi-middleware... but
does not show parallel stream processing.

I use one such parallel stream-processing generator in git_http_backend.py (
https://github.com/dvdotsenko/git_http_backend.py) Works well against
CherryPy's WSGI server. (The generator itself is in subprocessio.py - wraps
call to git into subprocess and relays back command output realtime without
caching the data to drive.)

Daniel.

Thanks for the explanation, Daniel. Though I don't think it justifies this
specific behavior of CherryPy's, it seems in practice that we shouldn't put
too much stock in write()'s behavior in general. I'll look into yielding
instead of write() -- more than anything else, I depend on write for its
implicit immediacy in sending data to the client, so if yielding doesn't
send the data across the wire "soon enough" for the client's user
experience, I'll have to stick with write().

- Yash

The short answer is: if you use yield and set "response.stream = True"
for that URL, that tells all of CherryPy "don't buffer the output", in
which case it behaves very much like write(). See
http://docs.cherrypy.org/stable/progguide/streaming.html

Robert Brewer

fuman...@aminus.org

From: cherrypy-users@googlegroups.com
[mailto:cherrypy-users@googlegroups.com] On Behalf Of Yash Parghi
Sent: Tuesday, August 14, 2012 8:18 AM
To: cherrypy-users@googlegroups.com
Subject: [cherrypy-users] Re: Dumping the request body on write in
CherryPyWSGIServer

Thanks for the explanation, Daniel. Though I don't think it justifies
this specific behavior of CherryPy's, it seems in practice that we
shouldn't put too much stock in write()'s behavior in general. I'll look
into yielding instead of write() -- more than anything else, I depend on
write for its implicit immediacy in sending data to the client, so if
yielding doesn't send the data across the wire "soon enough" for the
client's user experience, I'll have to stick with write().

- Yash

http://python.org/dev/peps/pep-3333/#buffering-and-streaming

Summary:

Don't use write()

Alternatives are, unfortunately, complex. I recommend to go for
full-blown generator as any in-between (inline yield's) solution will
quickly become small for you.

To simulate generator "in-line" try:

    start_response(..., ...)

    ...

    yield "snippet"

    ...

    yield "some more"

    ...

    return ['rest', 'of', 'response']

But real solution is make a looping generator class and just return it
(after start_response(... ))

I wish I could give you a simple example of smart generator, but there
is no simple example of smart generator that I know. This is relatively
there:
http://jimmyg.org/blog/2009/using-yield-statements-in-wsgi-middleware-ca
n-be-very-harmful.html but does not show parallel stream processing.

I use one such parallel stream-processing generator in
git_http_backend.py (https://github.com/dvdotsenko/git_http_backend.py)
Works well against CherryPy's WSGI server. (The generator itself is in
subprocessio.py - wraps call to git into subprocess and relays back
command output realtime without caching the data to drive.)

Daniel.

I'm new to WSGI and CherryPy, and I'm trying to understand why
CherryPyWSGIServer reads and discards the request body when my app first
calls write(). The code snippet that does this is footnote [1] below
from CherryPyWSGIServer (we're using 3.1.1, but the behavior looks the
same in later versions).

This is what's happening in our app, as best I can tell:

1. an unchunked request comes in with a large body and a Content-Length
header

2. my app starts reading the body from wsgi.input

3. at some arbitrary point mid-read, my app sends back a progress update
to the client via write() (which is, as far as cherrypy is concerned,
just some plain old bytes)

4. cherrypy consumes the rest of the request body as part of sending the
response headers before sending the data passed to write().

I see the rationale in the CherryPyWSGIServer code, from the HTTP 1.1
spec -- "the server SHOULD NOT close the transport connection until it
has read the entire request" -- but I don't see how that entails reading
and discarding the request on the first write, since the connection
isn't being closed at that point. Can anyone clarify/expand?

If that rationale stands for whatever reason, how _should_ my app use
write() without discarding the remainder of the request? Do I need to
make sure the entire request body has been read before I ever call
write()? Is that a WSGI expectation?

Thanks a lot -

Yash

[1]

if (not self.close_connection) and (not self.chunked_read):

    # Read any remaining request body data on the socket.

    ...

--
You received this message because you are subscribed to the Google
Groups "cherrypy-users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/cherrypy-users/-/Tt3Zg6vkh9sJ.
To post to this group, send email to cherrypy-users@googlegroups.com.
To unsubscribe from this group, send email to
cherrypy-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/cherrypy-users?hl=en.