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.

About these ads
This entry was posted in General. Bookmark the permalink.

One Response to EZProxy: Use qurl, not url, really

  1. Great tutorial and explanation. Urls with parameters always have some kind of problem and annoy me. I wish we could develop the notion of urls with post variables to stop the madness

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s