I have an Web application REST deployed in a JBoss 5.0: the Apache Solr.

In the Firefox 3.6 Windows, when typing the following URL in the location bar…
http://:/solr/videos/select/?q=cães& version=2.2& start=0& rows=10& indent=on
… the Firefox sends a request encoded in ISO-8859-1…
http://:/solr/videos/select/?q=c%E3es&version=2.2&start=0&rows=10&indent=on …
and the solr return no docs for this query.

In the Linux, firefox send the same query encoded in UTF-8…
http://:/solr/videos/select/?q=c%C3%A3es&version=2.2&start=0&rows=10&indent=on e
… and solr returns every doc indexed for cães (dogs).

Now, if you make the same experience in the Google or the Wikipedia, you will see that the Firefox always will encode requests in UTF-8. Why?

Curiously, looking at HTTP 1.1 REF, the default encoding would be ISO-8859-1.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1

Any idea?
Thx

I have a web application in WEB REST deployed in JBoss 5.0: the Apache Solr.

In Firefox 3.6 Windows version, typing the following URL in the Location Bar …
http://:/solr/videos/select/?q=cães&version=2.2&start=0&rows=10&indent=on
… the firefox send a request encoded in ISO-8859-1:
http://:/solr/videos/select/?q=c%E3es&version=2.2&start=0&rows=10&indent=on

… and solr return: no results found.

In Linux, the same query is encoded in UTF-8:
http://:/solr/videos/select/?q=c%C3%A3es&version=2.2&start=0&rows=10&indent=on
and the Solr return every document indexed for cães (dogs) .

Now, if you make the same experience in Google or Wikipedia, Firefox always will encode in UTF-8. Why???

Curiously, looking at HTTP 1.1 REF, the default encoding should be ISO-8859-1.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1

Thx,

I submit this:
http://www.google.com/search?q=%E2%80%A2

Firefox decodes %E2%80%A2 into a visible BULLET character.

When I edit the url, Firefox encodes is incorrectly as this:
http://www.google.com/search?q=%95

%95 is not a BULLET character in UTF-8. In Windows-1252, this is a BULLET, but in UTF-8, this is a MESSAGE WAITING character.

Firefox is misrepresenting my data-sending wishes!

Thoughts?

http://www.bernzilla.com/item.php?id=100

The perceived incremental threat to rendering UTF-8 in the location bar assumes that people are otherwise good parsers of URLs, which is consistently shown to be false. Attackers already paper “paypal.com” all over subdomains and path segments in a URL, because they know unsophisticated users won’t know the difference. On the other hand, the downside of refusing to render IDN/UTF-8 properly is that a very large portion of the net gets a second-class experience.

This isn’t an argument that “things suck so who cares if we make them worse,” it’s a reminder that, one the one hand, benefit has to be weighed against cost, and on the other, that url tinkering is not the way to keep people safe. We keep people safe by removing complex URL semantics as a thing we expect users to understand – by actively blocking known badness, and by providing stronger (verified, revocable) identity information the rest of the time.

Edward, yes- this is a gigantic, enormous win for the location bar usability. We will be focusing on this new i18n-enabled functionality whenever we talk about the AwesomeBar.