Bug 4136 - CLI input parameter charset management
: CLI input parameter charset management
Status: RESOLVED INVALID
Product: Logitech Media Server
Classification: Unclassified
Component: CLI
: 6.5b3
: All All
: P2 enhancement (vote)
: Future
Assigned To: Fred
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-18 03:30 UTC by Fred
Modified: 2014-08-13 09:48 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fred 2006-09-18 03:30:56 UTC
Currently, the CLI performs encoding of the incoming data ONLY if the charset parameter is present in the command. This enables extended commands/queries to accept parameters in a given charset (f.e. search parameters) and "legacy" commands/queries to work as before, mainly for paths. Internally, SlimServer does not encode paths in UTF8, they remain in the native charset, so encoding paths in UTF8 does not work "down the chain". There is however no easy way to determine what a given parameter is for legacy commands. For example, playlist play xxx accepts about anything as xxx...

This is logged as an enhancement request but the current logic for $request->fixEncoding() might well lead to bugs on UTF8 native systems.
Comment 1 Blackketter Dean 2006-09-18 11:41:26 UTC
fred, do you intend to fix this?
Comment 2 Fred 2006-09-18 12:01:20 UTC
Yes, if needed and time allows. This is more a reminder than a strongly needed feature.
Comment 3 Michael Herger 2008-11-04 03:48:38 UTC
Fred - is this still on the todo list?
Comment 4 Fred 2008-11-04 05:33:11 UTC
Strictly speaking yes. For non tagged commands, we have no way of knowing what the charset of the parameters are. This makes managing paths with international chars complicated. 

You may want to remove this "generic" bug and work on fixing its manifestations when they occur.
Comment 5 Michael Herger 2014-08-13 09:48:51 UTC
Closing following Fred's advice. It's been a while :-)