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 704240 - HTTP status code is lost when canceling an ongoing message
HTTP status code is lost when canceling an ongoing message
Status: RESOLVED OBSOLETE
Product: libsoup
Classification: Core
Component: Misc
unspecified
Other All
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2013-07-15 11:57 UTC by Andres Gomez
Modified: 2018-09-21 16:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
soup-message: Independent HTTP status code fields (12.06 KB, patch)
2013-07-15 11:57 UTC, Andres Gomez
none Details | Review

Description Andres Gomez 2013-07-15 11:57:27 UTC
Current status code property stores the HTTP status codes but also soup specific status codes.
    
When one of these specific status code happen, it may overwrite an existing HTTP status code so it is lost for later checkings.
    
For example, we may have received a 200 "OK" HTTP status code but chose to cancel any further processing. Later, we won't be able to check again which was the received HTTP status code when, for example, getting some information with SoupLogger.
Comment 1 Andres Gomez 2013-07-15 11:57:28 UTC
Created attachment 249184 [details] [review]
soup-message: Independent HTTP status code fields

Current status code property stores the HTTP
status codes but also soup specific status codes.

When one of these specific status code happen, it
may overwrite an existing HTTP status code so it
is lost for later checkings.

For example, we may have received a 200 "OK" HTTP
status code but chose to cancel any further
processing. Later, we won't be able to check again
which was the received HTTP status code when, for
example, getting some information with SoupLogger.

This patch adds another HTTP status code and
reason phrase properties so they can always be
checked if existing.

The current only user of this new field is the
SoupLogger.
Comment 2 Andres Gomez 2013-07-15 12:02:04 UTC
I commented this with Dan some days ago.

It seemed that the best way of easy solving this would be in the SoupLogger itself, as it is the piece in which it is really interesting to know the HTTP status code even when canceling.

However, it may be better actually to store this information in the SoupMessage itself, as the SoupLogger would have to trace any existing message.

Still, this may be only the first attempt for the definitive patch. Now, we are duplicating information since the HTTP status code and its reason will be in 2 different properties at the same time.

This patch is simple since it doesn't change any logic inside the SoupMessage but just stores the status code.

Maybe it would be better just to split the status codes in 2 totally different and non-overlapping propertis:
 * status code.
 * http status code.
Comment 3 Dan Winship 2015-02-10 11:58:08 UTC
[mass-moving all "UNCONFIRMED" libsoup bugs to "NEW" after disabling the "UNCONFIRMED" status for this product now that bugzilla.gnome.org allows that. bugspam-libsoup-20150210]
Comment 4 GNOME Infrastructure Team 2018-09-21 16:16:06 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/57.