After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 726348 - Display download progress as we get it
Display download progress as we get it
Status: RESOLVED FIXED
Product: ostree
Classification: Infrastructure
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: OSTree maintainer(s)
OSTree maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-03-14 14:33 UTC by Colin Walters
Modified: 2014-04-11 06:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
wip/chunked-http-status (7.12 KB, patch)
2014-03-14 14:33 UTC, Colin Walters
none Details | Review
wip/chunked-http-status (7.15 KB, patch)
2014-03-19 22:57 UTC, Colin Walters
committed Details | Review

Description Colin Walters 2014-03-14 14:33:07 UTC
This is a bit hacky right now, and to really test it I need an async
HTTP server via libsoup.
Comment 1 Colin Walters 2014-03-14 14:33:08 UTC
Created attachment 271902 [details] [review]
wip/chunked-http-status
Comment 2 Dan Winship 2014-03-16 20:59:05 UTC
(In reply to comment #0)
> This is a bit hacky right now, and to really test it I need an async
> HTTP server via libsoup.

I'm not sure what you mean... the code in the patch looks like it should do what you want.
Comment 3 Colin Walters 2014-03-19 22:57:55 UTC
Created attachment 272446 [details] [review]
wip/chunked-http-status

Send at just a byte at a time
Comment 4 Colin Walters 2014-03-19 22:58:31 UTC
(In reply to comment #2)
> (In reply to comment #0)
> > This is a bit hacky right now, and to really test it I need an async
> > HTTP server via libsoup.
> 
> I'm not sure what you mean... the code in the patch looks like it should do
> what you want.

Well it had one bug where I was not correctly accmulating an offset from the start, new patch attached.

But with that fixed...if I call soup_message_unpause() early, it sends a partial result.  If I only call soup_message_unpause() after I'm done writing, then I won't be writing partial bytes to the client socket.
Comment 5 Dan Winship 2014-03-20 00:42:05 UTC
(In reply to comment #4)
> But with that fixed...if I call soup_message_unpause() early, it sends a
> partial result.  If I only call soup_message_unpause() after I'm done writing,
> then I won't be writing partial bytes to the client socket.

"Sends a partial result" meaning that it closes the connection before sending the number of bytes you'd declared in soup_message_headers_set_content_length()?

The way it's supposed to work (as seen in libsoup/tests/streaming-test.c) is that if you're using Content-Length encoding (which you are), then you first explicitly set the Content-Length header (which you do), and then soup-message-io will continue to expect new chunks until you reach that length, and will just pause the message if it gets ahead of you.

(If you use chunked or terminated-by-EOF encoding, you don't need to pre-declare the length, but you need to call soup_message_body_complete() to signal when you're done.)


Also: libsoup's built-in Content-Range handling only works when you provide the whole response body ahead of time, so if you're streaming the result, you need to handle that yourself.
Comment 6 Colin Walters 2014-03-20 03:11:39 UTC
(In reply to comment #5)

> "Sends a partial result" meaning that it closes the connection before sending
> the number of bytes you'd declared in
> soup_message_headers_set_content_length()?

Ah no, this is different...I just want to write some bytes to the socket, but not the whole file.

> The way it's supposed to work (as seen in libsoup/tests/streaming-test.c) is
> that if you're using Content-Length encoding (which you are), then you first
> explicitly set the Content-Length header (which you do), and then
> soup-message-io will continue to expect new chunks until you reach that length,
> and will just pause the message if it gets ahead of you.

Ah.  Hrm.  I'll look at that, thanks.

> (If you use chunked or terminated-by-EOF encoding, you don't need to
> pre-declare the length, but you need to call soup_message_body_complete() to
> signal when you're done.)

Yeah, I don't want to do chunked (just to avoid another variable) and definitely not EOF as that would kill speed.
 
> Also: libsoup's built-in Content-Range handling only works when you provide the
> whole response body ahead of time, so if you're streaming the result, you need
> to handle that yourself.

Right, that's fair enough.  In this case I'm not trying to mix the two, I just want a slow socket.
Comment 7 Colin Walters 2014-04-11 06:00:26 UTC
Decided to push this one without the test for now.