Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Incorrect UPnP error codes
21-01-2013, 03:29 PM
Post: #1
Incorrect UPnP error codes
The UPnP Device Architecture specification defines the following error codes on page 53:

401 Invalid Action No action by that name at this service.
402 Invalid Args Could be any of the following: not enough in args, too many in args, no in arg by
that name, one or more in args are of the wrong data type.
403 (Do Not Use) (This code has been deprecated.)
501 Action Failed May be returned in current state of service prevents invoking that action.
......

ohNet is currently returning the following:

501 for invalid XML argument name etc. (should be 402) - see lines 964, 987, 1005, 1017, 1020, 1033, 1036, 1053 of DviServerUpnp.cpp

501 for no action by that name (should be 401) - see line 190 of DviService.cpp

502 for action not available (should presumably be 501) - see line 165 of DviService.cpp
Find all posts by this user
21-01-2013, 04:14 PM
Post: #2
RE: Incorrect UPnP error codes
Well spotted. I won't get this done immediately but have added a task to the backlog to make sure it isn't forgotten.

Out of interest, do the current error codes cause problems with any control points or did you just happen to notice the deviation from the standard while doing unrelated debugging?
Find all posts by this user
21-01-2013, 04:45 PM (This post was last modified: 21-01-2013 04:47 PM by simoncn.)
Post: #3
RE: Incorrect UPnP error codes
(21-01-2013 04:14 PM)simonc Wrote:  Well spotted. I won't get this done immediately but have added a task to the backlog to make sure it isn't forgotten.

Out of interest, do the current error codes cause problems with any control points or did you just happen to notice the deviation from the standard while doing unrelated debugging?

I found this because I added an operation to a service, and I changed the name of a parameter on another operation. These changes resulted in error codes that I wasn't expecting. (The parameter name change threw me at first, because the error code bore no relation to the cause of the problem.)

For service evolution, it's useful to be able to check the proxy error code for the expected value when a newer client is invoking an older server. For now, I've worked around this with temporary code.

Edit: In this case, the control point was MinimWatch (my own code).
Find all posts by this user


Forum Jump: