On Mon, 18 Jun 2007 10:50:10 +0200, "Mathias Dahl" mathias.dahl@gmail.com wrote:
No, the former. URL-ENCODE encodes the spaces from the file names, to pluses, so even if I use the nice function you provided me with, it does not work, I have to replace the pluses with either a space or %20.
CL-USER 1 > (hunchentoot:url-encode "A Space") "A%20Space"
Which version of Hunchentoot are you using?
Sorry, no no, I am serving my mp3-files using Apache only. I was just explaining that for some reason a plus character does not work in URLs if I want to download a file from my web server using Firefox. This problem has nothing to do with Hunchentoot.
Well, in /some/ cases a plus does work. Actually, some days ago Peter Seibel asked me whether I could switch back Hunchentoot's behaviour to emitting "+" instead of "%20". But "%20" is the right thing to do.
Maybe we should drop this, I am not trying to critizise Hunchentoot, I am just discussing whether I need to do my (replace-all (replace-all (url-encode file-name ...) ...) ...) or if there was any way to do this directly using Hunchentoot. The foo defun you gave me is close, but returns those pluses that does not seem to work in Firefox/Apache.
It /should/ work with the FOO function I sent /and/ the latest version of Hunchentoot. You might also want to look at how CL-WEBDAV works.
Maybe you thought I also used Hunchentoot to deliver the mp3-files to the client, when I just lets Apache to do it.
If you use Hunchentoot to deliver the files, it should be able to cope with both "+" and "%20".
Cheers, Edi.