[ic] decoding problem
lists at gmnet.net
Fri Nov 14 22:10:43 UTC 2008
On Fri, 2008-11-14 at 20:28 +0100, Stefan Hornburg (Racke) wrote:
> Rick Bragg wrote:
> > I guess this is more of an apache thing than IC, sorry if this is off
> > topic for this list, but I was wondering if anyone here has a solution.
> > I am using the "filesafe" filter and creating directories and symlinks
> > for images on the fly based on item titles. For example, someone creates
> > an item with the title Test_"Test's" and uploads an image, IC builds a
> > directory and uploads the image to the following URL.
> > http://test.com/Test_%22Test%27s%22/test.jpg
> > That is all working perfect, however, when I try to browse or link to
> > it, it gets re-written to the following and causes a 404.
> > http://test.com/Test_"Test's"/test.jpg
> > Is this something that apache is doing? or is this just a browser issue?
> > What should I do to make sure that it does not get decoded like this?
> I would just collapse all unusual characters and whitespace to underscores.
> It avoids this problem, the URL looks better and it is common practice
> in blogs etc.
> LinuXia Systems => http://www.linuxia.de/
> Expert Interchange Consulting and System Administration
> ICDEVGROUP => http://www.icdevgroup.org/
> Interchange Development Team
That is the best idea.
Here is a filter that I call urlsafe. It removes leading/trailing
spaces, then inner spaces are converted to underscores then all non-word
characters are just removed.
CodeDef urlsafe Filter
CodeDef urlsafe Description Make a clean URL safe string
CodeDef urlsafe Routine <<EOR
my $val = shift;
$val =~ s/^\s+//g;
$val =~ s/\s+$//g;
$val =~ s/ /_/g;
$val =~ s/\W//g;
Maybe this will help someone.
This message has been scanned for viruses and
dangerous content by Green Mountain Network, and is
believed to be clean.
More information about the interchange-users