[hunchentoot-devel] url-encoding file names
Hi! I am encoding file names using the url-encode function in Hunchentoot. However, it encodes chars such as space and / as well, which makes at least my browser (Firefox) or web server not understand that they are indeed links to files I have shared. So I have this workaround: (defun replace-all (string part replacement &key (test #'char=)) "Returns a new string in which all the occurences of the part is replaced with replacement." (with-output-to-string (out) (loop with part-length = (length part) for old-pos = 0 then (+ pos part-length) for pos = (search part string :start2 old-pos :test test) do (write-string string out :start old-pos :end (or pos (length string))) when pos do (write-string replacement out) while pos))) (defun replace-some-encoded (file-name) ;; Some chars should not be encoded, apparently... (replace-all (replace-all file-name "+" "%20") "%2F" "/")) (defun url-encode-file-name (file-name) (replace-some-encoded (hunchentoot:url-encode file-name :utf-8))) The above gives URLs like these: http://myserver/Tommy%20K%C3%B6rberg%2FTommy%20K%C3%B6rberg%20-%20Stad%20i%2... And without the workaround I get this: http://klibb.com/muuartist/Tommy+K%C3%B6rberg%2FTommy+K%C3%B6rberg+-+Anthem.... I searched the doc for "file name" to see if there was some special method suited for encoding file names with path information but could not find one. Do I need the above workaround? Thanks! /Mathias
On Sat, 16 Jun 2007 18:16:10 +0200, "Mathias Dahl" <mathias.dahl@gmail.com> wrote:
I am encoding file names using the url-encode function in Hunchentoot. However, it encodes chars such as space and / as well, which makes at least my browser (Firefox) or web server not understand that they are indeed links to files I have shared.
This question actually has nothing to do with Hunchentoot but with understanding what URL-encoding is. See for example: http://www.blooberry.com/indexdot/html/topics/urlencoding.htm Forward slashes, for example, have special meaning in URLs and thus /must/ be encoded. And the spaces won't confuse Firefox. What you probably want is (something similar) to this (untested): (defun foo (pathspec) (format nil "~{~A/~}~A" (mapcar #'url-encode (rest (pathname-directory pathspec))) (url-encode (file-namestring pathspec)))) HTH, Edi.
This question actually has nothing to do with Hunchentoot but with understanding what URL-encoding is.
I realized that after posting, URL-encoding is for encoding values that otherwise has special meaning in URLs.
And the spaces won't confuse Firefox.
That does not work for me. I cannot say if it is Firefox or Apache that mess up. These two URLs are supposed to be interchangeable, but only the latter works for me when I paste it in the address field of Firefox: http://myserver/somepath/Tommy+K%C3%B6rberg/Tommy+K%C3%B6rberg+-+Stad+i+ljus... http://myserver/somepath/Tommy%20K%C3%B6rberg/Tommy%20K%C3%B6rberg%20-%20Sta... The former gives me this: ==== Object not found! The requested URL was not found on this server. If you entered the URL manually please check your spelling and try again. If you think this is a server error, please contact the webmaster. Error 404 myserver ... ====
What you probably want is (something similar) to this (untested):
(defun foo (pathspec) (format nil "~{~A/~}~A" (mapcar #'url-encode (rest (pathname-directory pathspec))) (url-encode (file-namestring pathspec))))
Ah, yes it is, thanks! That is what I wondered if it existed in Hunchentoot :). Maybe it could be an addition to Hunchentoot for your next release, url-encode-path-parts or similar? With an optional format parameter. Modulo my problem with "+" vs "%20", of course... /Mathias
And the spaces won't confuse Firefox.
That does not work for me. I cannot say if it is Firefox or Apache that mess up. These two URLs are supposed to be interchangeable, but only the latter works for me when I paste it in the address field of Firefox:
Sorry for not reading what you wrote. You wrote "spaces" and I just assumed you meant the spaces converted to pluses. Spaces might work as they are, I haven't tested, but still url-encode encodes to these pluses so I have to convert them to %20 (or maybe just a space, I will test this). /Mathias
On Sun, 2007-06-17 at 23:41 +0200, Mathias Dahl wrote:
pluses so I have to convert them to %20 (or maybe just a space, I will test this).
Yes, spaces works as they are, so one don't need to encode them at all actually.
You do, as a matter of fact ;-) Seriously: Space characters are illegal in URLs (since the different parts of a request line a separated by spaces - Iff your client would send: 'GET /files/stuff/honk zisch HTTP/1.1' your server would be rather confused about protocol version 'zisch'). Now, since the early Web was often build by designers rather than programmers _some_ browsers silently convert spaces to '%20' sequences ... but i wouldn't rely on that feature - i've seen browsers that don't. Cheers, RalfD
/Mathias _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Sun, 17 Jun 2007 23:35:52 +0200, "Mathias Dahl" <mathias.dahl@gmail.com> wrote:
That does not work for me. I cannot say if it is Firefox or Apache that mess up. These two URLs are supposed to be interchangeable, but only the latter works for me when I paste it in the address field of Firefox:
http://myserver/somepath/Tommy+K%C3%B6rberg/Tommy+K%C3%B6rberg+-+Stad+i+ljus...
http://myserver/somepath/Tommy%20K%C3%B6rberg/Tommy%20K%C3%B6rberg%20-%20Sta...
Well, only the latter URL was created with Hunchentoot's URL-ENCODE, right?
The former gives me this:
==== Object not found!
The requested URL was not found on this server. If you entered the URL manually please check your spelling and try again.
If you think this is a server error, please contact the webmaster. Error 404 myserver ... ====
Where does this error message come from? Not from Hunchentoot it seems.
http://myserver/somepath/Tommy+K%C3%B6rberg/Tommy+K%C3%B6rberg+-+Stad+i+ljus...
http://myserver/somepath/Tommy%20K%C3%B6rberg/Tommy%20K%C3%B6rberg%20-%20Sta...
Well, only the latter URL was created with Hunchentoot's URL-ENCODE, right?
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.
The former gives me this:
==== Object not found!
The requested URL was not found on this server. If you entered the URL manually please check your spelling and try again.
If you think this is a server error, please contact the webmaster. Error 404 myserver ... ====
Where does this error message come from? Not from Hunchentoot it seems.
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. 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. Maybe you thought I also used Hunchentoot to deliver the mp3-files to the client, when I just lets Apache to do it. Thanks! /Mathias
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.
CL-USER 1 > (hunchentoot:url-encode "A Space") "A%20Space"
Aha! Look: MP3SEARCH> (hunchentoot:url-encode "A Space") "A+Space"
Which version of Hunchentoot are you using?
Dare I say it? :) 0.4.11... I'm sorry I didn't report the version earlier I'll try the new version. /Mathias
On Mon, 18 Jun, 2007 at 14:10:10 -0400, Edi Weitz wrote:
Which version of Hunchentoot are you using?
Dare I say it? :) 0.4.11...
Ha! That's prehistoric!!
I'm using 0.4.5 for development. It works fine. So I don't bother with upgrade :-) -- Registered Linux User #124759
Too late, the new version is already compiled into my core file... ;) /Mathias On 6/19/07, Igor Plekhov <penguin@ocean.vvo.ru> wrote:
On Mon, 18 Jun, 2007 at 14:10:10 -0400, Edi Weitz wrote:
Which version of Hunchentoot are you using?
Dare I say it? :) 0.4.11...
Ha! That's prehistoric!!
I'm using 0.4.5 for development. It works fine. So I don't bother with upgrade :-)
-- Registered Linux User #124759 _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
participants (4)
-
Edi Weitz -
Igor Plekhov -
Mathias Dahl -
Ralf Mattes