<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Hi</div><br><div><div>On 7 Apr 2014, at 10.25, Per Buer <<a href="mailto:perbu@varnish-software.com">perbu@varnish-software.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi Jason.<div><br></div><div>Docwilco from Fastly has written an URL encoder/decorder VMOD that you can use. You could run it through it twice or patch it do uppcase/lowercase the encoding.</div><div><br></div>
<div><a href="https://www.varnish-cache.org/vmod/url-code">https://www.varnish-cache.org/vmod/url-code</a><br></div><div><br></div><div>Varnish itself doesn't try to interpret the URL much.</div><div><br></div><div>Per.</div>
</div></blockquote></div><br><div>Thanks Per, that looks great!</div><div><br></div><div>Would you agree this would be better resolved in varnish itself?</div><div>It looks as though in default VCL it uses hash_data(req.url) - but I question the intension. If the intension is to cache distinct URLs then it needs to use hash_data(urldecode.from.core(req.url)) or hash_data(req.urldecoded).</div><div>In using hash_data(req.url) it appears to say that it wants to cache distinct binary representations of a URL, which to be is not the intention.</div><div><br></div><div>For reference, RFC3986 (I don't know if this means much though) it says in 2.1:</div><div><br></div><div><div></div><blockquote type="cite"><div>The uppercase hexadecimal digits 'A' through 'F' are equivalent to</div><div> the lowercase digits 'a' through 'f', respectively. If two URIs</div><div> differ only in the case of hexadecimal digits used in percent-encoded</div><div> octets, they are equivalent. For consistency, URI producers and</div><div> normalizers should use uppercase hexadecimal digits for all percent-</div><div> encodings.</div></blockquote></div><div><br></div><div>So I wonder if really the varnish core should decode before it hashes?</div><div>I guess this is a very edge scenario though so not likely to be touched since it only affects outside latin characters and most places will use a more friendly URL or latin characters where it doesn't have any issue.</div><div>What are your thoughts? Do you think it worth raising or best to just leave it be and work around it elsewhere?</div><div><br></div><div>Regards,</div><div><br></div><div>Jason</div></body></html>