New issue
Advanced search Search tips
Starred by 10 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Mar 2017
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Sign in to add a comment

Issue 74424: Square brackets in URI not escaped when submitting GET's

Reported by, Feb 28 2011

Issue description

Chrome Version       : 9.0.597.98 (Official Build 74359)
URLs (if applicable) : Any URL with square bracket "[" or "]" in  
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: ?
  Firefox 3.x: OK
       IE 7/8: OK

What steps will reproduce the problem?
1. Enter any URL with "[" or "]".
2. Notice that, unlike "{" or "}", Chrome does not escape these upon issuing a GET request when hitting <Enter>.

What is the expected result?
In all other browsers, "[" and "]" are escaped (to %5B and %5D) like any other "unwise" character specified in RFC2396 section 2.4.3: "Data corresponding to excluded characters must be escaped in order to be properly represented within a URI".

What happens instead?
Chrome doesn't threat all "unwise" characters the same. While "{" and "}" are indeed escaped (to %7B and %7D) as per the recommendation, the same doesn't apply to "[" and "]" which remains unescaped.

Please provide any additional information below. Attach a screenshot if

An idempotent side-effect of the above behavior is that while Chrome does unescape/render an entered URI with %5B and %5D into "[" and "]", hitting refresh works (applies escaping) while hitting <Enter> in the location bar does not. In other words, Chrome's escape(uri) != escape(unescape(escape(uri))).

Comment 1 by, Mar 3 2011

Labels: -Area-Undefined Area-Internals Feature-Omnibox

Comment 2 by, Mar 3 2011

Comment 3 by, Jul 19 2011

Owner: ----

Comment 4 by, May 23 2012

Yes I have this issue as well; I want to use xpath expressions as URI in my web app, but found out that unfortunately the [] should be escaped according to RFCs. Now Chrome doesn't do it, so I wonder how necessary it is. 

Chrome keeps it as is and rewrites to[@version=%22black-market%22][@year=%222008%22][@month=%22August%22]/revenue

Comment 5 by, May 23 2012

Hmm.  If I type "[food]", the search URL that comes back escapes the brackets.  So I'm not precisely sure what Chrome's behavior here is.

Comment 6 by, May 23 2012

Yes, but it seems that is just done on the search-string, before it insert at the end of ""
But if you type in[food] , it remains as-is.

Comment 7 by, May 23 2012

That seems to happen in IE as well.

Comment 8 by, Aug 10 2012

Project Member
Status: IceBox
Closing old bug as obsolete. Please file a new bug (with details) if this problem is still occurring for you.

Comment 9 by, Aug 10 2012

Status: WontFix

Comment 10 by, Aug 10 2012

I'm puzzled as to why this was closed. I clearly describe a behavior which is not in accordance with the RFC (2396). The user confirms this bug and it has not been fixed and is neither old nor obsolete. 

Do you accept patches if I fix it myself?

Comment 11 by, Aug 10 2012

Comment 7 suggests that we match IE, which is basically our goal here.

I'm not opposed to fixing, but it has to be clear there's a bug here.  Citing an RFC doesn't prove that, because (very sadly) the real world does not match RFCs in all sorts of ways.  If other browsers and an RFC disagree, we will generally match other browsers.

What actually breaks when doing this?

Comment 12 by, Aug 10 2012

I didn't see anything break; I was just wondering how I should implement my webapp and whether I should escape '[' and ']'. The fact that the RFC and chrome didn't agree, caught my attention. 

I have been told it's good to follow RFC's, but I don't know about the practical considerations in this particular case.

Comment 13 by, Aug 10 2012

It's sad to hear that MSIE, a browser notoriously known for making its own rules, sets the standard. I don't have MSIE here, but 7 and 8 did use escaping, as does the latest Firefox (Requesting[i] actually sends a GET to, as RFC2396 recommends).

The issue comes up when using Chrome for purposes that exercise these symbols, usually stuff sitting on top of a REST gateway (In my case using Chrome to develop and access OData resources: Same issue would show with JSON, Xpath etc. used in an URI. Whether or not it breaks anything is obviously up to the parser on the receiving end. To work around this on our OData gateway, I sanitize and escape before handing the request, but Chrome really ought to handle this - just as it does with other characters, and as other browsers do.

Comment 14 by, Aug 11 2012

Labels: -Pri-2 Pri-3
Status: Untriaged
If Firefox always escapes these when typed in, that's an argument for escaping.  I wish I had specified the IE version I tested in comment 7; I think it was IE 9.  It would be nice to test that as well.

We would certainly at least consider any patches to fix this.  Fixing this correctly might be tricky -- when I last checked we seemed to have several different tables in different places that covered separate aspects of escaping and unescaping, so fixing at the correct place might be difficult.

Comment 15 by, Jan 17 2013

I can confirm that ff 16 escapes "[" and "]" correctly (according to RFC) but Chrome 17 doesn't. I stumbled over this bug while writing server code and wondered why javas URI parser breaks when parsing some url containing "[" or "]".
Offtopic & ore than odd: Google's Spider sends these (incorrectly), too and reports error in webmaster tools ...

Comment 16 by, Mar 10 2013

Project Member
Labels: -Area-Internals -Feature-Omnibox Cr-Internals Cr-UI-Browser-Omnibox

Comment 17 by, Mar 28 2017

Status: WontFix (was: Untriaged)
I have just checked both by entering searches and URLs that Chrome (version 56) and Firefox (version 52) do not escape [] in URLs.

Per comment #7, I'm closing this as WontFix unless someone finds that a different major browser does escape.  "If other browsers and an RFC disagree, we will generally match other browsers."

Sign in to add a comment