- From: Philip Taylor (Webmaster, Ret'd) <P.Taylor@Rhul.Ac.Uk>
- Date: Mon, 04 Oct 2010 20:26:59 +0100
- To: "Jukka K. Korpela" <jkorpela@cs.tut.fi>
- CC: W3C Validator Community <www-validator@w3.org>
Jukka K. Korpela wrote: >> 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. Right, we agree with what the browser sends, but you have not explained what happens in order for Google to interpret it as a & parameter-delimiter rather than as the start of a shortref (or "entity reference", if you prefer). Because Google /does/ treat it as an & parameter delimiter, and it would be useful to document how/why. > >> 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. Yes, the HTML source contains & > 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;. Right, so the browser sends a simple ampersand, which the server treats as you describe. >> 3) The browser sends %26, > > No, that would be incorrect. OK, so again you have said what does /not/ happen, but not what does happen. Would you care to go further ? I really think this whole issue is poorly understood "in the wild", and if this thread could lead to a full explanation of what happens within the browser, at the HTTP level, and at the server end, this might be of benefit to others in the future. ** Phil.
Received on Monday, 4 October 2010 19:27:38 UTC