A Debug ID would be more helpful here.

I don't see any HTTP requests in there at all.

Are you sure that debug output encompasses the HTTP requests? They should always be logged if they're actually made.

FYI, the URL I'm using is http://ezport.lib.ebscopub.net:2060/login.aspx?direct=true&db=a9h&AN=85407980&site=ehost-live.

For you to use it, I'd need to add a username and password for you.

Wait, what's the actual problem that you're reporting? I assumed you were referring to URL-bar saving, hence my comments above about HTTP requests, but now it sounds like you're talking about just loading a proxied web page. What are the steps to reproduce here?

Enter the following URL:

http://ezport.lib.ebscopub.net:2048/login?url=http://search.ebscohost.com/login.aspx?direct=true&db=a9h&AN=85407980&site=ehost-live

Login with dstillman/Zotero

If Zotero is disabled in Firefox, you'll see this sequence:

1. /login port 2048, 200
2. /login port 2048, 302
3. /connect port 2048, 302
4. /login.aspx port 2060, 302,
5. /Community.aspx port 2060, 302
6. /plink port 2072, 302
7. /ehost/detail port 2072, 200

With Zotero enabled, you'll see:

1. /login port 2048, 200
2. /login port 2048, 302
3. /connect port 2048, 302
4. /login.aspx port 2060, 302,
5. /Community.aspx port 2060, 302
6. /plink port 2072, 302
7. /plink port 2072, 302
8. /login port 2048, 302
9. /plink port 2072, 200
10. /ehost/detail port 2072, 200

The access in (6) is the problem one. It is transmitted with no cookies, which results in the redirect that results in the (8) and (9) accesses. However, the access in (9) is a retransmission of the one in (7). That particular URL of ours can only be used once, result in the error result seen in the body of (9).

Craig

Is this code specific to Ezproxy? I don't quite understand exactly what a duplicate transaction without the cookies will learn in the general case.

Note that in the case I've been able to duplicate, only a single duplicate transaction occurs. However, we've seen in our error logs where a loop appears to occur in the background. I've seen the loop send us well over 10,000 erroneous transactions per hour. It's all in the background so the user of the browser never notices a problem, other than perhaps some browser and network slowness. A packet trace of one of these loops from the Ezproxy side showed that these cookieless accesses were involved.

I have noted that when Ezproxy is in proxy-by-hostname mode, the extra access does not occur. This agrees with our logs, which never seem to show loops from Ezproxy instances in proxy-by-hostname mode.

I've fixed this for 4.0 and verified that requests (8) and (9) no longer happen. Unless you see a way (6) would be problematic on its own, or you know a way to get mappings from EZProxy ports to domains without it, we will keep doing it.

This fix is available in the 4.0 Branch dev XPI, so he could check with that (which at this point is mostly just 4.0 Beta 1 plus this fix).

I'm not sure if we'll do a Beta 2, but 4.0 Final will indeed be released by the time Firefox 20 ships.

I have downloaded the dev build and verified from the client end that the extra access to the vendor site no longer appears to occur. (I have not yet verified from the host end.)

It seems like OCLC and Zotero could collaborate to eliminate even the one extra access. For example, the hostname corresponding to the redirected-to port could be added as an extra "X-" HTTP header when redirecting a session to a new port. There would be no extra information exposure, as the hostname can always be inferred by doing what Zotero does now.

The EZProxy code applies only to Zotero for Firefox.

4.0 is compatible with FF 17 upwards.
Anyone using a pre-17 FF version (which is the latest ESR release) doesn't receive security updates anymore and should be strongly discouraged from using the internet ...