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.

Many web apps can handle “&” and “&amp;” 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.