Skip to main content


If you are using a Hotmail or Outlook email address, please change it now, as Microsoft is rejecting all email from our service outright.
Topic: Extend the HTTP & FTP support (Read 274 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Extend the HTTP & FTP support

Feature request: Extend the FTP and HTTP support.
- Support .CUE from FTP & HTTP.
- Load album art from FTP & HTTP. (On HTTP, try to load only the first filename from Preferences / Display / file names list, to prevent server ban after too many 404.)
- Better FTPS & HTTPS support. Make it less dependent on system libraries. I use foobar2000 on a stick and it doesn't work on several PCs I tried.

Thank you!

Re: Extend the HTTP & FTP support

Reply #1
Cue and album art, noted, will check.

What exactly doesn't work on several PCs and what Windows versions do they run?

Encryption is currently handled by Windows system libraries. Switching to something else (OpenSSL) means considerable installer size growth and extra maintenance work (security updates!) for a niche feature in an audio player.

Re: Extend the HTTP & FTP support

Reply #2
What exactly doesn't work on several PCs and what Windows versions do they run?
It's not that they don't work on several PC, exactly, but site-download progs like Teleport Pro regard https as being like gopher.
It is an unsupported protocol.  It isn't planned to be upgraded, as the author seems to think that http will always be available as a fall back.

As for what doesn't work.  By default tsl 1.2 & 1.3 don't work on Win7 without some amount  of work.  For example I had the upgrade mentioned but not the registry entries.  Adding them fixed nothing -- had to uninstall the patch from 2 years ago, then reinstall it after the registry changes were made.  While this wasn't terribly painful for tsl 1.2+1.3,  future payload encryption mechanisms may not be so easily ported to one's OS unless the work was done in the past.

Having the _option_ to automatically translate+try non (s) protocols helps future-proof existing code, longer.  It also can speed up downloads of large numbers of files where newer sec-protos take 2-3 seconds to connect / file, vs. 0 for non-encrypted varieties.

So I would not suggest switching to another encryption method, just allowing it to be disabled, would be sufficient.  It's not
like audio players/extensions are usually secret -- and if a user wants that, they can compress & encrypt it with something like
7z and completely outside the FB2k ecosphere.

I noted this in downloading https files for a linux distro that took at least 2 sec/request where the http request had no such delay.

Given the distro has hundreds of thousands of files, 2s/file becomes significant.  Not all applications know to reuse a connection, so putting it in 1 place like libraries, would benefit many less advanced download programs.

MOD Edit: Fix quote

SimplePortal 1.0.0 RC1 © 2008-2020