On Mon, Mar 22, 2010 at 9:11 PM, Michael Snoyman <span dir="ltr">&lt;<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">On Mon, Mar 22, 2010 at 4:20 PM, Jeremy Shaw <span dir="ltr">&lt;<a href="mailto:jeremy@n-heptane.com" target="_blank">jeremy@n-heptane.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>On Sun, Mar 21, 2010 at 12:04 AM, Michael Snoyman <span dir="ltr">&lt;<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>&gt;</span> wrote:</div><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>That made perfect sense, thank you for doing such thorough research on this.</div><div><br></div><div>I&#39;ve attached two files; test1.html is UTF-8 encoded, test3.html is windows-1255 (Hebrew). On my system, both links point to the same location, implying to me that you are spot on that UTF-8 should always be used for URLs. I had made a mistake with my test on Friday; apparently we only have the encoding issue with the query string.</div>


</div></blockquote><div><br></div></div><div>Hmm. Those files do not contain value urls. The strings in the hrefs contain characters that are not in the limited set allowed by the URI spec. The part that is true is that even though the files have different encodings (utf-8 vs windows-1255) the characters in the strings are the same, so the urls are the same. I guess maybe the reason you put in invalid characters is because it is hard to test whether different encodings matter if you are only testing characters that are represented by the same octets in both encodings. </div>


<div><br></div></div></blockquote></div><div>Well, you guessed correctly at my reason for constructing the files as I did. Not this is actually relevant to the discussion at hand, I believe that it is valid HTML to put values in the HREF fields that are not in the appropriate character range and assume the web browser will take care of things. &lt;/off-topic&gt;</div>
</div></blockquote><div><br></div><div><br></div><div>I believe the html 4.0 explicitly states that it is illegal here (though it recommends that user agents do something sensible anyway):</div><div><br></div><div><a href="http://www.w3.org/TR/REC-html40/appendix/notes.html#non-ascii-chars">http://www.w3.org/TR/REC-html40/appendix/notes.html#non-ascii-chars</a></div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><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>The big trip up would be forms with method GET. The form submission is handled by taking the form set data, encoding it as application/x-www-form-urlencoded, and then append ? and the encoded data to the end of the action. If the action already contained a ?, that would not work out.</div>


<div><br></div></div></blockquote></div><div>You can&#39;t have a URL containing a ?; the closest you can come is a URL containing an *escaped* ?, which will simply be absorbed by the [String] piece of the URL. Unless I&#39;m missing your point here.</div>
<div class="im">
<div><br></div></div></div></blockquote><div> </div><div>What I meant is that if the url supplied to the action already had a query string, then something undesirable would probably happen. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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>encodePathInfo  / decodePathInfo is probably a good choice of names. Adding them to web-encodings is likely useful, but I will just use local copies in urlt, because web-encodings brings in too many extra dependencies that I don&#39;t want at that level.  I don&#39;t think I will export them though, so it should not cause a conflict.</div>


<div><br></div></div></blockquote></div><div>I have no problem with that decision, but out of curiosity which dependencies are problematic? The only non-HP packages are failure, safe, text and wai. The only ones which could in theory be eliminated are failure and safe; if there is desire for me to do so, I&#39;ll look into it.</div>
</div></blockquote><div><br></div><div>Well, I see no reason to make all of urlt depend on failure, safe, text, wai, and web encodings when two small local functions would do the trick. Using the functions from web-encodings would not really increase compatibility / interoperability in any way, and I don&#39;t expect a lot a bug fixes that will have to be applied to multiple locations.</div>
<div><br></div><div>Remember that I plan to split urlt up into a few pieces soon. I don&#39;t want happstack users complaining they have to install wai, or wai users complaining they have to install happstack. Even if happstack is ported to wai, there are extra layers that happstack adds which might benefit from some extra functions in urlt. </div>
<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 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></div><div>Also, my implementation is not quite right. It escapes more characters than is strictly required. path segments have the following ABNF:</div>
<div><br></div><div><div>      path_segments = segment *( &quot;/&quot; segment )</div>
<div>      segment       = *pchar *( &quot;;&quot; param )</div><div>      param         = *pchar</div><div><br></div><div>      pchar         = unreserved | escaped |</div><div>                      &quot;:&quot; | &quot;@&quot; | &quot;&amp;&quot; | &quot;=&quot; | &quot;+&quot; | &quot;$&quot; | &quot;,&quot;</div>


<div><br></div><div>Also, . and .. are allowed in a path segment, but have special meaning. Not sure what we want to do about those. I like the property that *any* String value is automatically escaped and has no special meaning. So the same should be true for &#39;.&#39; and &#39;..&#39;. But if you do need to use &#39;.&#39; and &#39;..&#39; for some reason, there is no mechanism to do it in the current system. Though I am not sure what a compelling use case would be, so I am ok with just not allowing them for now. </div>


</div><div><br></div></div>
</blockquote></div></div>I&#39;m not sure if they have meaning at the HTTP level. At the HTML level, they specify relative paths, but I don&#39;t think they mean anything once it enters HTTP.</blockquote><div><br></div><div>
 I&#39;m not sure what to do with this information. It is true that they may be normalized by the browser before they are passed to the server. But urlt is being used primarily to create URLs that will be used in HTML pages. So, I think will still have to decide what to do with them.. Also, we shouldn&#39;t assume that the client normalized the .. stuff. Perhaps a malicious client won&#39;t in the hopes that it can retrieve <a href="http://example.com/../../../../etc/passwd">http://example.com/../../../../etc/passwd</a> or something. </div>
<div><br></div><div>- jeremy</div></div>