Hello:
I’m trying to confirm if this is a result of using “ForceHTTPSLogin” in the EZproxy config. Only because this URL change seems to have happened right after its implementation.
I could find a reference here:
http://www.oclc.org/support/services/ezproxy/documentation/changes.en.html
“allows starting point URLs to take the form:
http://ezproxy.yourlib.org:2048/login?qurl=http%3a%2f%2fwww.somedb.com
Special characters that appear after qurl= must be “hex quoted,” especially & to %26, = to %3d and ? to %3f. As such, the URL (one or more line breaks were added in each of the following two examples for display purposes; examples without added line breaks are available):
http://ezproxy.yourlib.org:2048/login?url=http://www.somedb.com/search?
name=db&option=1
would need to be changed to:
http://ezproxy.yourlib.org:2048/login?qurl=http%3a%2f%2fwww.somedb.com
%2fsearch%3fname%3ddb%26option%3d1
This alternate form is not required, but is provided for instances where using a character encoded URL is useful.”
For example, if you run the encoded URL (i.e. the URL after the “qurl” parameter) through a decoder ( http://www.asiteaboutnothing.net/c_decode-url.html ), it reverts through the regular, plain URL.
I’m not sure that the encoded URL is the problem here. More likely, the network that the mobile user is connected to may not have the standard SSL port 443 open.
I’m seeing this qurl switch when using a desktop browser as well.
I’ll post whatever I can find out later.
And yes: the NYCCT library site is painfully slow.