From 674d0d41207f465259a3576fbc48f3b9f74010b0 Mon Sep 17 00:00:00 2001 From: Robby Findler Date: Thu, 12 Oct 2006 13:23:16 +0000 Subject: [PATCH] added John Stone's message to a comment svn: r4565 original commit: a98abdc45f37747d8ffcc9b345972009ec45e683 --- collects/net/uri-codec-unit.ss | 61 +++++++++++++++++++++++++++++++++- 1 file changed, 60 insertions(+), 1 deletion(-) diff --git a/collects/net/uri-codec-unit.ss b/collects/net/uri-codec-unit.ss index 344fa74..8c1f158 100644 --- a/collects/net/uri-codec-unit.ss +++ b/collects/net/uri-codec-unit.ss @@ -6,7 +6,7 @@ #| People often seem to wonder why semicolons are the default in this code, -and not ampersands. Here's the best answer we have: +and not ampersands. Here's are the best answers we have: From: Doug Orleans To: plt-scheme@list.cs.brown.edu @@ -34,6 +34,65 @@ _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-scheme + + + + + +From: John David Stone +To: plt-scheme@list.cs.brown.edu +Subject: Re: [plt-scheme] Problem fetching a URL +Date: Wed, 11 Oct 2006 11:36:14 -0500 +X-Mailer: VM 7.19 under Emacs 21.4.1 + +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA1 + + Danny Yoo: + + > > Just out of curiosity, why is current-alist-separator-mode using + > > semicolons by default rather than ampersands? I understand that + > > flexibility is nice, but this is the fifth time I've seen people hit this + > > as a roadblock; shouldn't the default be what's most commonly used? + + Robby Findler: + + > It is my understanding that semi-colons are more standards compliant. + > That's why it is the default. + + According to the RFC1738 (http://www.ietf.org/rfc/rfc1738.txt), +semicolons and ampersands are equally acceptable in URLs that begin with +`http://' (section 5, page 17), but semicolons are ``reserved'' characters +(section 3.3, page 8) and so are allowed to appear unencoded in the URL +(section 2.2, page 3), whereas ampersands are not reserved in such URLs and +so must be encoded (as, say, &). RFC2141 +(http://www.ietf.org/rfc/rfc2141.txt) extends this rule to Uniform Resource +Names generally, classifying ampersands as ``excluded'' characters that +must be encoded whenever used in URNs (section 2.4, page 3). + + The explanation and rationale is given in Appendix B +(``Performance, implementation, and design notes,'' +http://www.w3.org/TR/html401/appendix/notes.html) of the World Wide Web +Consortium's technical report defining HTML 4.01. Section B.2.2 +(``Ampersands in URI attribute values'') of that appendix notes that the +use of ampersands in URLs to carry information derived from forms is, in +practice, a serious glitch and source of errors, since it tempts careless +implementers and authors of HTML documents to insert those ampersands in +URLs without encoding them. This practice conflicts with the simple and +otherwise standard convention, derived from SGML, that an ampersand is +always the opening delimiter of a character entity reference. So the World +Wide Web Consortium encourages implementers to use and recognize semicolons +rather than ampersands in URLs that carry information derived from forms. + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.5 (GNU/Linux) +Comment: Processed by Mailcrypt 3.5.8+ + +iD4DBQFFLR16bBGsCPR0ElQRAizVAJddgT63LKc6UWqRyHh57aqWjSXGAJ4wyseS +JALQefhDMCATcl2/bZL0bw== +=W2uS +-----END PGP SIGNATURE----- + |#