doc/bugs/osm_KML_maps_icon_path_have_a_trailing_slash.mdwn

   1 This is not a problem on Apache webservers because they, oddly enough, ignore trailing slashes on paths (maybe some `PATH_INFO` magic, no idea). But basically, in our wiki, the paths to the icon tags are generated with a trailing slash. An excerpt of our [KML file](http://wiki.reseaulibre.ca/map/pois.kml):
   2
   3     <Style id="/tag/up">
   4     <IconStyle>
   5     <Icon>
   6     <href>http://wiki.reseaulibre.ca//tag/up/icon.png/</href>
   7     </Icon>
   8     </IconStyle>
   9     </Style>
  10
  11 Notice the trailing `/` after the `icon.png`. This breaks display on nginx - the file that gets served isn't the icon, but the frontpage for some reason. I followed the [[setup instructions|tips/dot cgi]] for Nginx that I just had to write because there weren't any, so maybe I screwed up some part, but it does seem to me that the trailing slash is wrong regardless.
  12
  13 (Also notice how the style tag is being turned over backwards by the HTML sanitizer here, cute. :P)
  14
  15 I wrote a crude hack for this, but this strikes me as a similar problem to the one we found in [[bugs/osm linkto() usage breaks map rendering]]. However, I am at a loss how to fix this cleanly because we cannot `will_render()` the tag icons, as they are already generated out there! Weird. Anyways, here's the stupid [[patch]]:
  16
  17 [[!format diff """
  18 diff --git a/IkiWiki/Plugin/osm.pm b/IkiWiki/Plugin/osm.pm
  19 index a7baa5f..c9650d0 100644
  20 --- a/IkiWiki/Plugin/osm.pm
  21 +++ b/IkiWiki/Plugin/osm.pm
  22 @@ -192,6 +192,7 @@ sub process_waypoint {
  23                 }
  24         }
  25         $icon = urlto($icon, $dest, 1);
  26 +       $icon =~ s!/*$!!; # hack - urlto shouldn't be appending a slash in the first place
  27         $tag = '' unless $tag;
  28         register_rendered_files($map, $page, $dest);
  29         $pagestate{$page}{'osm'}{$map}{'waypoints'}{$name} = {
  30 """]]
  31
  32 I'm not writing this to a branch out of sheer shame of my misunderstanding. ;) There also may be a workaround that could be done in Nginx too. --[[anarcat]]