EZProxy: Use qurl, not url, really

So, you send URLs to EZProxy, which say “take this other URL as a data value, and proxy it.”

There are two basic params you can use to send URLs to EZProxy:

1. &url, eg http://someproxy.university.edu/login?url=http://example.com/something?foo=bar&baz=1. Yeah, the URL is really jammed right in there without escaping/quoting. It may very well result in an illegal URL. But it works.

2. &qurl, eg http://someproxy.university.edu/login?qurl=http%3A%2F%2Fexample.com%2Fsomething%3Ffoo%3Dbar%26baz%3D1. With qurl, the url used as a payload is expected to be actually properly quoted for inclusion in a URL.

You may be using #1 right now because

• You didn’t know about qurl
• You consider qurl too confusing to debug, since you’ve got to look at those quoted urls
• It’s ‘too hard’ to generate the URL with the escaped value.

Stop, don’t use #1 anymore, use #2. #1 is an illegal violates-the-standard URL. It’s just part of our job to develop the skills and facilities with tools to deal with URI escaping, even if it’s more confusing.

At first it might seem that while it’s technically illegal, it doesn’t really matter, after all, it works. But here’s my story about how doing things not-right causes problems for you later.

I had the “url=unescaped” illegal version. Sure, it worked even though it was illegal. Here’s an example url. http://proxy.library.example.edu/login?url=http://somewhere.edu?foo=bar&baz=bam. Yeah, that works. But that URL then went through a Rails app that, since the URL was being generated into an html hyperlink, noted that the value had to be escaped to be legal for an HTML attribute, changing it into http://proxy.library.example.edu/login?url=http://somewhere.edu?foo=bar&baz=bam. Which was actually quite correct of Rails there. Then, EZProxy, when on-campus, redirected to the unproxied http://somewhere.edu?foo=bar&baz=bam. Which didn’t work, the vendor platform coudln’t handle the URL with “&” in it instead of “&”.

Many web apps can handle “&” and “&” interchangeably — which is probably a good idea, because the history of confusion around these things is such that they will get confused.  But this particular vendor platform could not, and I can’t exactly call it a bug that it doesn’t, no standard says it has to (the standard in fact says it’s illegal to include an unescaped “&” in a HTML document, even though many people do in hyperlinks!).

So, anyway, going with the EZProxy url=illegal variant led down this hole, where the URL ended up getting transmogrified by my pipeline.  Sticking to the legal qurl variant, all is just fine.

Do it right, you’ll save yourself debugging trouble later.