[libsoup] soup-cache: correctly handle conditional requests not returning 304

[Sergio Villar Senin <svillar src gnome org>]

commit 60978987dca7c2f6df86b2796c1463bcf843eed2
Author: Sergio Villar Senin <svillar igalia com>
Date:   Fri Jun 1 19:17:40 2012 +0200

    soup-cache: correctly handle conditional requests not returning 304
    
    If we do not get a 304 after a conditional request we have to refresh the
    cache contents for that resource. We should use the original SoupMessage to
    retrieve the new data from the resource (we were incorrectly using the
    SoupMessage used for the conditional request).
    
    The current strategy is clearly suboptimal as we ask again for the resource
    instead of directly using the data from the response of the conditional
    request. This will change once the cache is integrated into the streams
    stack.

 libsoup/soup-request-http.c |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)
---
diff --git a/libsoup/soup-request-http.c b/libsoup/soup-request-http.c
index 9f5c2da..86a9010 100644
--- a/libsoup/soup-request-http.c
+++ b/libsoup/soup-request-http.c
@@ -172,10 +172,12 @@ conditional_get_ready_cb (SoupSession *session, SoupMessage *msg, gpointer user_
 		}
 	}
 
-	/* The resource was modified, or else it mysteriously disappeared
-	 * from our cache. Either way we need to reload it now.
+	/* The resource was modified or the server returned a 200
+	 * OK. Either way we reload it. This is far from optimal as
+	 * we're donwloading the resource twice, but we will change it
+	 * once the cache is integrated in the streams stack.
 	 */
-	soup_session_send_request_async (session, msg, sadata->cancellable,
+	soup_session_send_request_async (session, sadata->original, sadata->cancellable,
 					 http_input_stream_ready_cb, sadata);
 }