GNOME Bugzilla – Bug 703200
SoupLogger doesn't print available headers if the message is cancelled before the body is received
Last modified: 2013-07-15 11:36:37 UTC
Created attachment 247921 [details] Modified get example showing that the logger doesn't print the headers of the response message if cancelling soon SoupLogger works so it would only print upon response when the "got-informational" or "got-body" signals have been received. This makes that we lose interesting information from the received headers if such signals are not received when, for example, we cancel the message prematurely. SoupLogger can make it better since it may have received the headers much sooner and it would be interesting for the developer to have them ASAP.
Forgot to provide instructions to run the "get" example with the modifications: With: $ ./examples/get -d -o http://www.igalia.com/ 2> /dev/null We will see the debug information coming from the logger thanks to the "-d" flag. Thanks to the "-o" flag, we will send the "body" data to "stderr" rather than "stoud" so it won't disturb us (we can also replace /dev/null with a file thanks to this). With current implementation, as I've added a cancel message request, we won't see the information from the response to be printed by the logger.
Created attachment 247923 [details] [review] [soup-logger] Upon response, print headers ASAP SoupLogger won't print any information upon response until the "got-body" or "got-informational" signals are received. If the response message has been cancelled or requeued first, we miss the headers information, even when we would have been already able to print it. Now, upon response, we print information with SOUP_LOGGER_LOG_MINIMAL or SOUP_LOGGER_LOG_HEADERS as soon as we receive the "got-headers" signal and will print the information with SOUP_LOGGER_LOG_BODY as soon as we receive the "got-body" or "got-informational" signals.
The reason it does it this way is because otherwise, when there are multiple requests running in parallel, you can't tell which bodies go with which headers. So one possibility would be to connect to ::finished on the message, and if you see a message finish before you printed the full response, then belatedly log it at that point.
(In reply to comment #3) > The reason it does it this way is because otherwise, when there are multiple > requests running in parallel, you can't tell which bodies go with which > headers. Right! > So one possibility would be to connect to ::finished on the message, and if you > see a message finish before you printed the full response, then belatedly log > it at that point. Yep, I think that could work.
Created attachment 248300 [details] [review] [soup-logger] On response, always print headers SoupLogger won't print any information upon response until the "got-body" or "got-informational" signals are received. If the response message has been cancelled or requeued first, we miss the headers information, even when we would have been already able to print it. Now, upon response, if the logging has not yet happened when the "finished" signal is triggered, we do perform the logging then.
Comment on attachment 248300 [details] [review] [soup-logger] On response, always print headers looks good
Thanks for the review. Pushed to master.