Bug 16435 – Something interpreting &pi. as π. Causing problems with form handling

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: DOM

[Faye Pearson]

I first saw this on the www.betfair.com site (I work for them).  If you're in the US you won't be able to check this site though.  The url for one of the frames is generated in javascript, and contains ?foo=bar&pi.regionId=GBR&pi.localeId=en&foo2=bar2.

What webkit attempts to load (according to the inspector is:

?foo=bar%CF%80.regionId=GBR%CF%80.localeId=en&foo2=bar2.

As you can see this means the form is improperly delimited and therefore fails.  If I view source I see a pi symbol in the URL, so I'm thinking that something is treating <ampersand><token><punctuation> as having an implicit semicolon before punctuation.

[Alexey Proskuryakov]

Other browsers have inconsistent behavior in this case - e.g., "&pi," is interpreted as "π," by Firefox, but not by IE 7. However, for "&pi." both agree that this is not a character reference.

You can work around this issue by encoding & in the source:

?foo=bar&pi.regionId=GBR&pi.localeId=en&foo2=bar2.

[Alexey Proskuryakov]

See also: bug 4948.

[Faye Pearson]

The code works fine in firefox and IE.  So that suggests that either Firefox is recovering from this in some other way or firefox doesn't exhibit this behaviour (any more?) v2.0.0.11.  View source shows the &pi. (in the window title) just fine, and not as pi symbols.  Is the behaviour for & consistent?  ie, it will always become an ampersand in all browsers, and not be left as & which would also mess up the form variables.

[Alexey Proskuryakov]

(In reply to comment #3)
> The code works fine in firefox and IE.

  As I said, the "&pi." works consistently. I was trying to figure out the scope of this problem, as other punctuation characters cause inconsistent behavior. Sorry for the confusion.

> Is the behaviour for & consistent?

  Yes.

[Ahmad Saleem]

[e-mail] - Are you familiar with this issue or have any test case from old days?

In my opinion, WPT has quite a lot of coverage around these encoding cases and also around how URLs are encoded via JS etc., if there will be any such cases or web-compat issue, it would be easily account for these cases. So I think we can mark this as "RESOLVED WONTFIX". Would appreciate your input.

[Alexey Proskuryakov]

Definitely fixed by HTML5 parser, or even earlier. I doubt that we need any new tests for this.