- From: Jukka K. Korpela <jkorpela@cs.tut.fi>
- Date: Mon, 4 Oct 2010 22:05:57 +0300
- To: "W3C Validator Community" <www-validator@w3.org>
Philip Taylor (Webmaster, Ret'd) wrote: > David Dorward wrote: > >> You would use % notation if you wanted a literal >> & in the URL (as opposed to a separator between a value and the next >> key of the question string). >> >> Since you want a separator, you just need to represent the URL in >> HTML, so use & >> >> This is described in the explanation of error message that appears >> under the error in the validator's report > > OK, that what was I thought, but it was rather early in the morning > and my brain was not yet fully engaged. But it might be worth > exploring further what exactly happens with all three possibilities. David was correct in his explanation, as he usually is. > The page > http://web-consultants.org.uk/sites/tests/Ampersands.html > > contains all three, plus three additional exploratory tests. Testing can at most how what actually happens, not what _should_ happen. > Would you agree that the following occur : > > 1) No special treatment. The browser sends an unescaped ampersand, > the server /should/ treat it as the start of a shortref, but Google > elects not to and treats it as if it were escaped. Pardon? What the browser should send and actually sends is the "&" character. There is no such thing as "shortref" in the HTTP protocol, or "entity references", which is what you really mean. They belong to the realm of HTML, and HTTP as such is HTM-ignorant. > 2) The browser sends & which the server correctly interprets as &. If the HTML source contains &, then both the browser and the server would behave incorrectly. The browser shall interpret & as & and the server shall take & as yet another character, though acting as a separator (usually) when parsing the query part, and to the server, & should be just & followed by amp;. > 3) The browser sends %26, No, that would be incorrect. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Received on Monday, 4 October 2010 19:06:52 UTC