suzanne.soy/compatibility
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

added John Stone's message to a comment

Browse Source 
svn: r4565

original commit: a98abdc45f37747d8ffcc9b345972009ec45e683
This commit is contained in:
Robby Findler 2006-10-12 13:23:16 +00:00
parent 5d8304d58d
commit 674d0d4120
1 changed files with 60 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

61
collects/net/uri-codec-unit.ss
View File

@ -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 <dougorleans@gmail.com>
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 <stone@math.grinnell.edu>
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, &#38;). 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+ <http://mailcrypt.sourceforge.net/>
iD4DBQFFLR16bBGsCPR0ElQRAizVAJddgT63LKc6UWqRyHh57aqWjSXGAJ4wyseS
JALQefhDMCATcl2/bZL0bw==
=W2uS
-----END PGP SIGNATURE-----
|#