some bugs in the UDP API
Posted: Tue Apr 18, 2006 8:53 pm
I have just terminate the first fase of the development of my Anidb UDP client protocol with Twisted and Python (anidblib).
During tests I have found some bugs.
Content-type: text/x-rst
Anidb UDP API BUGS
=============
Basic
------
* Content encoding
- the current character encoding is us-ascii?
- the escape scheme for command option values is not html form encoding. Only "&" needs to be escaped with "&"
- typo: "<br>" should be "<br />"
- "'" (0x27) is silently replaced by "ยด" (0x60), so it never appears in strings
* General
- the 555 message sometimes use the "wrong" tag
- response data has always a trailing empty line, this should be documented.
* Flood Protection
- the 555 messages is issued too frequently. My client follows all documented requirements, maybe there are additional undocumented restrictions?
Authing Commands
----------------------
* AUTH
- username should be converted to lowercase, but what about password?
* LOGOUT
- typo: "recieve" should be "receive"
Notify Commands
---------------
typo: "from other the" should be "from the other"
* PUSH
- 271 and 272 are not present in the return codes list
- why the field order in 271 and 272 differs from that in 293/292?. Even the names used in the documentation differs!
- why not just send all the available data with the notifications (as the message body)?
- since MESSAGE command limits the length of the subject and the body, maybe this should be documented here too.
* NOTIFYACK
- the 281 return code is present in the return codes list but not documented here.
Data Commands
-------------------
* ANIME
- romaji/kanji/english/other/synonym/short name are globally unique?
* EPISODE
- special character used in epno should be documented
* FILE
- the field {str anidbfilename} is not selectable by fcode; this means that it is not returned when acode or fcode is given
- the file selection by anime, group and epno may identify more than one file, but only one is returned.
Misc Commands
------------------
* STATS
- the returned data contains 7 fields, not 6; moreover there is a field documented(?) as int4 but, actually, of about 46 bits ::
[['3657', '46120', '169049', '3174', '140781', '35972377698960', '168']]
- creqs should be documented
* TOP
- returned fields should be documented
[list][/list][list=][/list]
During tests I have found some bugs.
Content-type: text/x-rst
Anidb UDP API BUGS
=============
Basic
------
* Content encoding
- the current character encoding is us-ascii?
- the escape scheme for command option values is not html form encoding. Only "&" needs to be escaped with "&"
- typo: "<br>" should be "<br />"
- "'" (0x27) is silently replaced by "ยด" (0x60), so it never appears in strings
* General
- the 555 message sometimes use the "wrong" tag
- response data has always a trailing empty line, this should be documented.
* Flood Protection
- the 555 messages is issued too frequently. My client follows all documented requirements, maybe there are additional undocumented restrictions?
Authing Commands
----------------------
* AUTH
- username should be converted to lowercase, but what about password?
* LOGOUT
- typo: "recieve" should be "receive"
Notify Commands
---------------
typo: "from other the" should be "from the other"
* PUSH
- 271 and 272 are not present in the return codes list
- why the field order in 271 and 272 differs from that in 293/292?. Even the names used in the documentation differs!
- why not just send all the available data with the notifications (as the message body)?
- since MESSAGE command limits the length of the subject and the body, maybe this should be documented here too.
* NOTIFYACK
- the 281 return code is present in the return codes list but not documented here.
Data Commands
-------------------
* ANIME
- romaji/kanji/english/other/synonym/short name are globally unique?
* EPISODE
- special character used in epno should be documented
* FILE
- the field {str anidbfilename} is not selectable by fcode; this means that it is not returned when acode or fcode is given
- the file selection by anime, group and epno may identify more than one file, but only one is returned.
Misc Commands
------------------
* STATS
- the returned data contains 7 fields, not 6; moreover there is a field documented(?) as int4 but, actually, of about 46 bits ::
[['3657', '46120', '169049', '3174', '140781', '35972377698960', '168']]
- creqs should be documented
* TOP
- returned fields should be documented
[list][/list][list=][/list]