Bug 23135 – REGRESSION: Query parameters are sometimes incorrect in URL

• Status: RESOLVED
• Resolution: FIXED
• Component: Page Loading

[Chris Laprun]

Exhibited with a JSR-286 portlet with a resource URL with JBoss Portal 2.7 (head version). I'm expecting to see requests with a query part being similar to: action=f&cacheability=PAGE&id=dodemo instead, once in a while (I haven't been able to figure out what triggers the issue reliably), I get a query part similar to: action=f&cacheability=PAGE&di=dodemo (note that id param becomes di). I first thought it was a Portal bug (and spent quite a bit of time trying to figure it out) but can only replicate the issue on WebKit r39572. The portlet works fine with Safari 3.2.1 and Firefox 3.0.5.
Steps to reproduce (though it might be a little overkill):
1. get latest version of JBoss Portal 2.7 from subversion http://anonsvn.jboss.org/repos/portal/branches/JBoss_Portal_Branch_2_7/
2. get it to run (cd build; ant deploy-all - assuming you have JBoss AS 4.2.x installed and configured)
3. go to http://localhost:8080/portal
4. you should see an exception on the console as reported at https://jira.jboss.org/jira/browse/JBPORTAL-2271

[Alexey Proskuryakov]

The steps to reproduce are not particularly easy - would it be possible for you to make a demo installation available somewhere?

[Chris Laprun]

Will try to setup something...

[Chris Laprun]

Actually, thinking about it more, you will not see the issue unless you have access to the HTTP requests that are issued to JBoss AS and have the opportunity to examine them. Setting up a demo portal will not help as you wouldn't have access to that information. I will see if I can create a portlet that more specifically exhibits the issue.

[Alexey Proskuryakov]

We can see HTTP requests with tcpdump (as long as it's not HTTPS), or by using a debug proxy such as Fiddler or Charles.

[Chris Laprun]

You should see the issue at http://bug23135.dyndns.org/
Note that the problem has been going on for a while: I have tried several older versions back to r34xxx of WebKit and the ones that haven't crashed on me have all exhibited the issue.

[Chris Laprun]

I have to bring down that system for tonight, I'll restore access tomorrow.

[Alexey Proskuryakov]

I've been able to access the site, and saw the problem occur - but now it is unavailable again. I'll try later, as we still need to find out what's going on.

[Chris Laprun]

Currently experiencing NAT problems with my router... Same config, different results. Go figure! :( Sorry about that.
Hopefully I'll get it sorted out soon so that I can restore access.

[Daryl Pinkal]

(In reply to comment #0)
> Exhibited with a JSR-286 portlet with a resource URL with JBoss Portal 2.7
> (head version). I'm expecting to see requests with a query part being similar
> to: action=f&cacheability=PAGE&id=dodemo instead, once in a while (I haven't
> been able to figure out what triggers the issue reliably), I get a query part
> similar to: action=f&cacheability=PAGE&di=dodemo (note that id param becomes
> di). I first thought it was a Portal bug (and spent quite a bit of time trying
> to figure it out) but can only replicate the issue on WebKit r39572. The
> portlet works fine with Safari 3.2.1 and Firefox 3.0.5.
> Steps to reproduce (though it might be a little overkill):
> 1. get latest version of JBoss Portal 2.7 from subversion
> http://anonsvn.jboss.org/repos/portal/branches/JBoss_Portal_Branch_2_7/
> 2. get it to run (cd build; ant deploy-all - assuming you have JBoss AS 4.2.x
> installed and configured)
> 3. go to http://localhost:8080/portal
> 4. you should see an exception on the console as reported at
> https://jira.jboss.org/jira/browse/JBPORTAL-2271
> 

I have been running into this issue frequently as well although I cannot reliably reproduce it. In my case the parameter that is being changed is "SV" in the query: ".../?mode=js&SV=Prod&P=PO_29yAuC9VMGNVX48" It is reversed to become "VS". no other parameters are ever changed. It seems as though it is an issue with 2 letter parameter names.

[Daryl Pinkal]

I have been running into this issue frequently as well although I cannot reliably reproduce it. In my case the parameter that is being changed is "SV" in the query: ".../?mode=js&SV=Prod&P=PO_29yAuC9VMGNVX48" It is reversed to become "VS". no other parameters are ever changed. It seems as though it is an issue with 2 letter parameter names.

[Alexey Proskuryakov]

Daryl, would it be possible for you to make a demo installation available somewhere?

[Daryl Pinkal]

(In reply to comment #11)
> Daryl, would it be possible for you to make a demo installation available
> somewhere?
> 

Unfortunately I am unable to setup a demo installation. However, you may be able to duplicate the environment by setting up our product. Our product is a poll that is placed on 3rd party web sites via a script tag that makes a request for javascript from our server. The url for the javascript request is being modified. I have tried to reproduce the issue and have not been able to. I have been looking at our access logs (we are running Apache on FreeBSD using PHP/5.2.8) The query that was being modified was always the same one:
/?mode=js&VS=Prod&P=PO_8bFWsNeayUUcnLS
where VS should be SV. Obviously the parameter values varied from request to request. I couldn't find another query that was being modified.
I greped the access logs all queries returning a 500 server error due to the incorrect parameter and nearly all of the 4300+ errors were coming from a WebKit user agent. The 36 errors that weren't webkit were coming from a Googlebot agent. (Is google sharing webkit code?) Of the WebKit there were about a dozen coming from X11, ~30 coming from Macintosh, and ~10 coming from Windows. The rest (~3900) were coming from iPhone. I'm not sure what this says about normal distribution of traffic from these browsers but thought it useful to note that we're only seeing this issue from WebKit, and it's much more frequent in the iPhone. We will continue to monitor this issue and I will post here if I can figure out how to reliably reproduce the issue. As I mentioned previously, I have tested extensively using 
Safari for Windows - AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13
and 
iPhone - AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.1 Mobile/5G77 Safari/525.20

And I have not been able to reproduce it yet.

[Chris Laprun]

I should have more time now and I'll re-iterate my attempts to setup an accessible demo system.

[Christopher Blum]

I am able to reproduce this problem in Safari 4 Public Beta (5528.17) and Safari Public Beta (5528.16).

It tries to load a stylesheet with an url like this:
https://xingmodules.com/shindig/gadgets/proxy?url=XXX&gadget=XXX&fp=XXX&st=XXX

The stylesheet fails to load and when I look at the web inspector under "Resources" it shows the same url but every 2 letter parameter is reversed.

https://xingmodules.com/shindig/gadgets/proxy?url=XXX&gadget=XXX&pf=XXX&ts=XXX

Are there any workarounds?

[Alexey Proskuryakov]

Does this happen on a public URL? If not, can you arrange for access for someone from Apple or WebKit team?

We never had a chance to investigate this issue.

[Christopher Blum]

Hi Alexey,

I wrote you an e-mail with instructions how this bug can be reproduced.

Christopher

[Alexey Proskuryakov]

<rdar://problem/6902674>

[Alexey Proskuryakov]

Great, I have some understanding of what's going on now. Looks like this bug doesn't affect much client-side, we're sending an incorrect request in addition to the correct one, and only use the results of the correct one.

[Alexey Proskuryakov]

Fixed by Antti in <http://trac.webkit.org/projects/webkit/changeset/43876>.