GNOME Bugzilla – Bug 679673
Always returns "Not implemented" if Control URL contains %20
Last modified: 2021-05-17 16:29:13 UTC
I've no idea yet if that's a Service or ServiceProxy issue.
I have confirmed that if the Control URL contains 'space', e.g. '/SwitchPower1/Control xxx', then in runtime, the service constructor will assign the control_server_handler to the path '/SwitchPower1/Control%20xxx'. However, when the POST method (from action-invoke) from control point (client) arrives to the server, the path handler to the path '/SwitchPower1/Control xxx' will response which is undefined therefore a '501-Not Implemented' status error will return from libsoup. IMHO, this is a Service issue. When the Service initializes the path handler, it should make more efforts to guarantee the space conversion is right.
In soup-server.c, there is a callback function named got_headers () (line 821) which will (fully) decode the URL. So if the Control URL is '/SwitchPower1/Control xxx' in service.xml, in the current implementation the gupnp server will publish this URL as '/SwitchPower1/Control%20xxx', the client will request '/SwitchPower1/Control%20xxx'. But as soon as the request header from the client arrives the server, libsoup will decode this URL and change it as '/SwitchPower1/Control xxx' (note that '%20' is decoded as ' '). This is the reason to cause this bug. So even though a user writes the control URL as '/SwitchPower1/Control%20xxx' at first place, libsoup will change it to a literal whitespace. Thus, the SetTarget can't find the correct handler then issuing a 'Not Implemented' error with code 501
I think we can close this bug as long as we mention loudly in our documentation that "Don't use whitespace or %20 in URLs".
-- 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/gupnp/-/issues/30.