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 745067 - Requests are reloaded when a conditional request doesn't return NOT_MODIFIED
Requests are reloaded when a conditional request doesn't return NOT_MODIFIED
Status: RESOLVED OBSOLETE
Product: libsoup
Classification: Core
Component: Misc
2.49.x
Other Linux
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on: 744788
Blocks:
 
 
Reported: 2015-02-24 08:19 UTC by Carlos Garcia Campos
Modified: 2018-09-21 16:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Do not reload modified resources after a conditional request (17.36 KB, patch)
2015-02-24 08:42 UTC, Carlos Garcia Campos
none Details | Review

Description Carlos Garcia Campos 2015-02-24 08:19:36 UTC
When the result of a conditional request is that the resources has been modified, the conditional request itself returns 200 and the body has already been read, but we discard that and reload the resource again. I think we shouldn't complete the body io for conditional requests, so that in case of modified resource, we can create an input stream for the body and let the client read from it normally. The tricky part is that we need to move the conditional request response and io state to the original message.
Comment 1 Carlos Garcia Campos 2015-02-24 08:42:41 UTC
Created attachment 297735 [details] [review]
Do not reload modified resources after a conditional request
Comment 2 Dan Winship 2015-02-28 20:07:04 UTC
(In reply to Carlos Garcia Campos from comment #0)
> The tricky part is that we need to
> move the conditional request response and io state to the original message.

Yeah... I don't really like how this turned out. All the moving stuff between SoupMessages looks really tricky and fragile.

I think it would be better to just send the original SoupMessage, and if you get back 304 Not Modified, treat it similarly to how we treat redirect responses, with the original response being discarded and then the "redirected" response (ie, the cached response) being what gets returned to the caller. It seems like that would require a lot fewer changes.

(It would change the semantics of validation requests in a way that would be observable to the caller, but WebKit is really the only user of SoupCache, so if it doesn't break WebKit, I think that's fine.)
Comment 3 Rodrigo Costa 2015-05-25 16:01:55 UTC
This bug can cause problems to websites that send a xmlHttpRequest and expect that only one request be sent.
A server could avoid sending the last-modified date and close the connection to work around this issue.
Comment 4 GNOME Infrastructure Team 2018-09-21 16:21:49 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libsoup/issues/80.