<br><br><div class="gmail_quote">On Fri, Mar 19, 2010 at 2:41 PM, Jeremy Shaw <span dir="ltr"><<a href="mailto:jeremy@n-heptane.com">jeremy@n-heptane.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Mar 19, 2010 at 5:22 PM, Michael Snoyman <span dir="ltr"><<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>></span> wrote:<br></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>I am not going to have time to look at this again until Saturday or Sunday. There are a few minor details that have been swept under the rug that need to be addressed. For example, when exactly does should url encoding / decoding take place. It's not good if that happens twice or not at all.</div>
<div><br></div><font color="#888888"><div><font color="#000000"><font color="#888888"><br></font></font></div></font></div></blockquote></div><div>Just to confuse the topic even more: if we do real URL encoding/decoding, I believe we would have to assume a certain character set. I had to deal with a site that was encoded in non-UTF8 just a bit ago, and dealing with query parameters is not fun.</div>
<div><br></div><div>That said, perhaps we should consider making the type of PathInfo "PathInfo ByteString" so we make it clear that we're doing no character encoding.</div></div></blockquote><div><br></div>
</div><div>Yeah. I dunno. I just know it needs to be solved :) </div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">
<div></div><div>Another issue in the same vein is dealing with leading and trailing slashes, though I think this is fairly simple in practice: the web app knows what to do about the trailing slashes, and each plugin should always pass a leading slash.</div>
</div></blockquote><div><br></div></div><div>I am not quite sure what you mean 'each plugin should always pass a leading slash'. Pass to whom?</div><div><br></div><div>If we have:</div><div><br></div><div>MySite = MyHome | MyBlog Blog</div>
<div>MyBlog = BlogHome | BlogPost String</div><div><br></div><div>Then I would expect something like this:</div><div><br></div><div>formatMySite MyHome = "MyHome"</div><div>formatMySite (MyBlog blog) = "MyBlog/" ++ formatMyBlog blog</div>
<div><br></div><div>formatMyBlog BlogHome = "BlogHome"</div><div>formatMyBlog (BlogPost title) = "BlogPost/" ++ title</div><div><br></div><div>mkAbs = ("<a href="http://localhost:3000/" target="_blank">http://localhost:3000/</a>" ++)</div>
<div><br></div><div>(ignoring any escaping that needs to happen in title, and ignoring an AbsPath / PathInfo stuff).</div><div><br></div><div>But we could, of course, do it the other way:</div><div><br></div><div><div><br>
formatMySite MyHome = "/MyHome"</div><div>formatMySite (MyBlog blog) = "/MyBlog" ++ formatMyBlog blog</div><div><br></div><div>formatMyBlog BlogHome = "/BlogHome"</div><div>formatMyBlog (BlogPost title) = "/BlogPost/" ++ title</div>
<div><br></div><div>mkAbs = ("<a href="http://localhost:3000" target="_blank">http://localhost:3000</a>" ++)</div><div><br></div></div><div>There definitely needs to be some policy.</div><div><br></div><font color="#888888"><div>
- jeremy</div></font></div>
</blockquote></div><br><div>Then here's a proposal for both issues at once:</div><div><br></div><div>* PathInfo is a ByteString</div><div>* handleWai strips the leading slash from the path-info</div><div>* every component parses and generates URLs without a leading slash. Trailing slash is application's choice.</div>
<div><br></div><div>Regarding URL encoding, let me point out that the following are two different URLs (just try clicking on them):</div><div><br></div><div><a href="http://www.snoyman.com/blog/entry/persistent-plugs/">http://www.snoyman.com/blog/entry/persistent-plugs/</a></div>
<div><a href="http://www.snoyman.com/blog/entry/persistent-plugs/">http://www.snoyman.com/blog/entry%2Fpersistent-plugs/</a></div><div><br></div><div>In other words, if we ever URL-decode the string before it reaches the application, we will have conflated unique URLs. I see two options here:</div>
<div><br></div><div>* We specify that PathInfo contains URL-encoded values. Any fromUrl/toUrl functions must be aware of this fact.</div><div>* We change the type of PathInfo to [ByteString], where we split the PathInfo by slashes, and specify that the pieces of *not* URL-encoded. In order to preserve perfectly the original value, we should not combine adjacent delimiters. In other words:</div>
<div><br></div><div>/foo/bar/baz/ -> ["foo", "bar", "baz", ""] -- note the trailing empty string</div><div>/foo/bar/baz -> ["foo", "bar", "baz"] -- we don't need a leading empty string; *every* pathinfo begins with a slash</div>
<div>/foo%2Fbar/baz/ -> ["foo/bar", "baz", ""]</div><div>/foo//bar/baz -> ["foo", "", "bar", "baz]</div><div><br></div><div>I'm not strongly attached to any of this. Also, my original motivation for breaking up the pieces (easier pattern matching) will be mitigated by the usage of ByteStrings.</div>
<div><br></div><div>Michael</div>