- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Tue, 13 Nov 2012 18:13:46 +0900
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: Anne van Kesteren <annevk@annevk.nl>, uri@w3.org, public-iri@w3.org
On 2012/11/08 21:26, Julian Reschke wrote: > On 2012-11-08 12:52, Anne van Kesteren wrote: >> ... >>> What do you mean by "a query with a lone "%" can be the output of the >>> parser"? Does that mean that it is sent as such to the server? What do >>> servers do with it? Would it hurt to escape it to %25? Or is that >>> done in a >>> later stage? >> >> Servers appear to not pay much attention to it. http://www.w3.org/?% >> is an example. Escaping it to %25 seems dangerous compatibility wise. I don't think http://www.w3.org/?% is a good example, because that page doesn't accept query parts at all. A better example would be a page that actually depends on a query part. I just tested with http://www.google.com/?q=% and http://www.google.com/?q=%25. On Opera, I get the same result (a page with "%" in the search box), but the difference in the address field stays. When requesting the actual search, the difference (% vs. %25) stays if I keep Javascript on. It disappears when I switch it off. On Safari, an input of http://www.google.com/?q=% gets turned into http://www.google.com/?q=%25. As confirmed with Wireshark, the query leaves the browser as GET /?q=%25 HTTP/1.1. That means that Safari does convert the % to a %25. Chrome behaves more like Opera. I didn't find a way to switch off JavaScript (maybe I didn't look long enough), but that part isn't at the core of what we are testing here. Firefox is the same as Opera. IE also seems to be the same or similar. > That's something we should test (and potentially eliminate) instead of > making it mandatory. Did you mean the above tests, or something else? I'd definitely also like to see some tests on the server side. For example, what happens in Apache when it receives "%" vs. "%25"? What about other servers, frameworks, and so on. Regards, Martin. > > ... > > Best regards, Julian > >
Received on Tuesday, 13 November 2012 09:14:24 UTC