No artwork

[bubbleguuum]

(22-11-2012 08:56)simoncn Wrote:  

(22-11-2012 00:40)bubbleguuum Wrote:  @simon

Various UPnP software and hardware epic failing at URL encoding/decoding is a classic (that, and failing at XML encoding/decoding in very creative ways).

That's why I always generate URLs that require no percent encoding and no queries in path if the URL can be used by a recipient I have no control over.
Gzip+base64 is a good idea as it is decodable to the original string.

Naim is super slow at fixing its software, if they ever fix it.

I guess proxying Minimserver with BubbleUPnP Server could serve as a temporary workaround, as it will generate simple URLs that even the dumbest UPnP client should have no problem with.

Thanks for the suggestion to use gzip+base64. I'll look into doing this, either as an option or as the default approach. Having the client URL easily reversible to the original server-side path when reading trace logs is important to me for debugging purposes.

This would presumably explain why so many web page URLs contain extremely long unreadable strings!

An alternative to gzip+base64 is to use a md5sum of the file path.
That limits URL length at the (small) expense to have to store the md5sum => file path association in a file. Which is very easily done by using Java serialization on a HashMap for example. That's what I'm doing in BubbleUPnP Server. But in other scenarios I just use gzip+base64.