Ruby Forum Rails Germany > URL Encoding Problem

Posted by Jan Roesner (Guest)
on 30.07.2008 09:48
(Received via mailing list)
Hallo Leute,

nachdem ich mit einem Projekt von lighttpd auf die Kombination Apache
+Mongrel+Capistrano umgestiegen bin, habe ich ein lustiges Problem mit
URL's , dass mir seit einigen Stunden etwas Kopfschmerzen macht.
Folgende Situation:

Ich baue auf einer Seite Link's aus Kategorienamen zusammen, etwa so:

<% for category in @movings %>
  <%= link_to(category.to_s, :controller => "archive", :action =>
"Transporte-fuer-"+category.to_s) %>&nbsp;
<% end %>

Mit Hilfe einer passenden Route fange ich dabei den Kategorienamen bei
einem Klick als params[:permalink] und kann so die korrekte Seite
rendern.

Jetzt gibt es bei mir aber mehrere Kategorien nach einem Schema wie
diesem z.B.:

"Be-/Entladen & Transport" .... nicht gerade optimal, Slash, Space und
weitere Sonderzeichen, die escaped werden wollen. Aber Rails tut das ja
einwandfrei.

Die passende URL sieht dann so aus:

http://172.16.215.129/archive/Transporte-fuer-Be-%2FEntladen+%26
+Transport

Und auch wenn ich Sie von Hand anpasse auf:

http://172.16.215.129/archive/Transporte-fuer-Be-%2FEntladen%20%26%
20Transport

funktioniert alles wie erwartet. Zumindest auf meinen beiden
Dev-Systemen auf denen einmal WebRick und einmal lighttpd läuft.

Deploye ich jetzt auf mein Produktivsystem und klicke z.B. den Link an,
bekomme ich vom Indianer aber nur ein trockenes:

Not Found
The requested URL /archive/Transporte-fuer-Be-/Entladen+&+Transport was
not found on this server.

Interessant dabei ist, dass im production-log der Aufruf des
Zielcontrollers nicht mal ankommt. Muss also definitiv eine Apache Issue
sein, ich bin mir nur keiner Schuld bewusst. Das dumme ist, dass selbst
wenn ich die URL komplett von Hand sauber codiere:

http://172.16.215.129/archive/Transporte-fuer-Be-%2FEntladen%20%26%
20Transport

der Fehler der gleiche bleibt. Ich stehe gerade etwas auf dem Schlauch,
möchte ungern eine Sonderbehandlung für solche Kategorien einbauen. Kann
mich jemand von Euch in die richtige Richtung schubsen?

Gruss und Dank
Jan Roesner
jan [a t] roesner [d o t] it
Posted by Stefan Frank (mugwump)
on 30.07.2008 10:06
(Received via mailing list)
puuh, aber die URLs sehen schon hübsch hässlich aus, oder?! Es löst 
nicht das ursprüngliche Apache-Problem, aber mit acts_as_permalink auf
der Category  kann man dieser (und vermutlich noch drei dutzend
weiterer Encoding-Probleme) recht einfach aus dem weg gehen und die
URLs bleiben trotzdem lesbar. Wir benutzen ständig routes mit solchen
permalinks und hatten bislang noch keine Probleme.

Grüßestefan


Am 30.07.2008 um 09:47 schrieb Jan Roesner:
Posted by Ralf Graf (Guest)
on 30.07.2008 10:11
(Received via mailing list)
Hallo Jan,

Am 30.07.2008 um 09:47 schrieb Jan Roesner:
> nachdem ich mit einem Projekt von lighttpd auf die Kombination Apache
> +Mongrel+Capistrano umgestiegen bin, habe ich ein lustiges Problem mit
> URL's , dass mir seit einigen Stunden etwas Kopfschmerzen macht.
>

damit habe ich mich voriges Jahr auch mal zeitaufwändig
rumgeschlagen. ;)

Ich habe da so ein Ding mit Tags, die manchmal komische Zeichen
enthalten können, z.B. "geo:long=13.41644":
http://www.uninformation.org/tag/geo%253Along=13%252E41644
Und es kam genau zu dem Phänomen, was Du beschreibst.

Ich habe das dann so gelöst:

Bei der Darstellung (obiges Bsp., rechts bei den "verwandten Tags")
formatiere ich die Links mit einem Helper, der den Tag in "tag" 
für  die Darstellung als link_to-Parameter aufbereitet:

def tag_encode(tag)
   URI.escape(tag,/[\.:]/)
end

Im Template steht dann:
link_to tag, tag_path(tag_encode(tag)) usw.

Im Controller dekodiere ich das dann wieder, "params[:id]" enthält den
Tag:
URI.unescape(params[:id])

Das funktioniert dann mit Apache und Mongrel. Ich weiß nicht mehr
genau, was die Ursache für das unterschiedliche Verhalten mit "reinem"
Mongrel-Entwicklungsserver und der Apache/Mongrel-Kombination auf dem
Live-Server ist, es hat irgendwas mit der Art und Weise zu tun, wie
mod_proxy "komische Zeichen" in URL behandelt.

viele 
GrüßeRalf
Posted by Andreas Roedl (Guest)
on 30.07.2008 12:01
(Received via mailing list)
Hallo,

2008/7/30 Jan Roesner <jan@roesner.it>:
> nachdem ich mit einem Projekt von lighttpd auf die Kombination Apache
> +Mongrel+Capistrano umgestiegen bin, habe ich ein lustiges Problem mit
> URL's , dass mir seit einigen Stunden etwas Kopfschmerzen macht.

Die Frage sei gestattet: warum? Also warum bist Du auf Apache +
Mongrel umgestiegen?


Andreas
Posted by Jan Roesner (Guest)
on 30.07.2008 13:32
(Received via mailing list)
Hallo Leute,

Danke erstmal für die Hinweise.


Am Mittwoch, den 30.07.2008, 12:00 +0200 schrieb Andreas Roedl:
> Hallo,
> 
> 2008/7/30 Jan Roesner <jan@roesner.it>:
> > nachdem ich mit einem Projekt von lighttpd auf die Kombination
Apache
> > +Mongrel+Capistrano umgestiegen bin, habe ich ein lustiges Problem
mit
> > URL's , dass mir seit einigen Stunden etwas Kopfschmerzen macht.
> 
> Die Frage sei gestattet: warum? Also warum bist Du auf Apache +
> Mongrel umgestiegen?

Ich musste auf einen anderen Server umziehen, das Projekt ist gewachsen,
und ich will für eine eventuell traffic lastigere Zukunft gewappnet
sein. Später weitere Application Server z.B. via EC2 hinzuzufügen ist
bei dem Konstrukt Apache + Mongrel Cluster wesentlich einfacher, und zu
Capistrano kann ich nur sagen: genial, vorher war deployen wesentlich
krampfiger.

Zu dem Problem. Mitterweile lässt es sich auf die Rewrite Engine des
Apachen eingrenzen.

Die Regel die eigentlich alles passende an den Mongrelcluster
durchreichen sollte, matcht aus mir unverständlichen Gründen nicht:

RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]

Das Problem scheint der eigentlich sauber umgesetzte Slash (%2F) zu
sein. Ersetze ich diesen durch ein anderes Zeichen, z.B. ein "-", so
findet ein Rewrite statt und ein Routingerror von Rails ist das
Ergebnis, was ja zumindest ok ist.

Ich habe jetzt an der RegEx ein wenig rumgespielt, bekomme aber kein
Match für diese URL's hin. Ergebnis wird wohl sein, dass ich wie von
Ralf vorgeschlagen ein separates en- bzw. decoding mit einem Helper
selber machen werde. Ich hätte es nur gern verstanden, bin aber auch zu
pragmatisch veranlagt ... gerade bei einer Applikation im
Produktivstatus.

Dank an alle.

Gruss
Jan Roesner
jan [a t] roesner [d o t] it