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 697084 - Drop "unhandled status code" warnings
Drop "unhandled status code" warnings
Status: RESOLVED FIXED
Product: gssdp
Classification: Other
Component: General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GUPnP Maintainers
GUPnP Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-04-02 07:22 UTC by Jens Georg
Modified: 2019-02-22 09:29 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Handle only "200 OK" response as valid SSDP response (1.24 KB, patch)
2014-07-08 12:43 UTC, Jussi Kukkonen 		committed Details | Review
Do not use g_warning() when receiving malformed SSDP messages (1.49 KB, patch)
2014-07-08 12:44 UTC, Jussi Kukkonen 		committed Details | Review

Description Jens Georg 2013-04-02 07:22:53 UTC 
Or make them a DEBUG. Some devices, such as the D-Link DAP-1522 apparently answer to the SSDP requests with a proper HTTP 404 which spams a lot of scary warnings:

+ Trace 231710

  • #2 parse_http_response
    at gssdp-client.c line 870 






Comment 1


Jussi Kukkonen





          2014-07-08 12:43:35 UTC
        



Created attachment 280150 [details] [review]
Handle only "200 OK" response as valid SSDP response






Comment 2


Jussi Kukkonen





          2014-07-08 12:44:13 UTC
        



Created attachment 280151 [details] [review]
Do not use g_warning() when receiving malformed SSDP  messages






Comment 3


Jussi Kukkonen





          2014-07-08 12:47:35 UTC
        



So the first patch is a refactoring: SSDP responses can only have 200 as result so we can handle the error case only once, when parse_http_response fails().

Second changes warnings into debugs in your case and the one that's annoying me constantly: A device in my network uses SSDP (but doesn't even try to be a UPnP device) and forgets the "\r\n" in the end.






Comment 4


Jens Georg





          2014-07-09 06:40:18 UTC
        



Review of attachment 280151 [details] [review]:

+1






Comment 5


Jens Georg





          2014-07-09 06:40:27 UTC
        



Review of attachment 280150 [details] [review]:

+1






Comment 6


Jussi Kukkonen





          2014-07-09 08:32:10 UTC
        



Thanks, pushed both patches.