Re: Forms/CGI urls: '&' in HREF attributes

Roy T. Fielding (fielding@avron.ICS.UCI.EDU)
Thu, 09 Feb 1995 15:44:35 -0800

To: "Daniel W. Connolly" <>
Subject: Re: Forms/CGI urls: '&' in HREF attributes 
In-Reply-To: Your message of "Thu, 09 Feb 1995 12:54:24 CST."
Date: Thu, 09 Feb 1995 15:44:35 -0800
From: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
Message-Id:  <>

> There's an unfortunate interaction between the x-www-urlencoded
> syntax for form data submission and SGML attribute value literal
> syntax. This came up shortly after I started running the validation
> service, and I thought we had discussed the problem, but it seems
> to be getting worse, and not better.

Yes, I brought this up at the San Jose IETF regarding the proposed
encoding for the z39.50 and z39.50s URLs.  The solution though is not
to change the syntax within forms parsers.  There are really three solutions:

1) some browsers are buggy, so fix them.

2) never use "&" as part of the definition of any URL.

3) use a real FORM when form-based URL parameters are desired.

It is abnormal for parameters to a form to be included in a link
(in fact, I think TimBL would consider this a violation of the idempotent
aspect of GET).

The ";" character is already reserved in many URLs for indicating
parameters *prior* to the query information.  It would have been nice
for that to have been the original ACTION=GET encoding, but there's
nothing we can do about that now.  I think it would be better to live
with the above three solutions than to attempt to change every forms
parser and browser on the web.

Hmmmmmmmm.....what does CGI do.......crap!  My NCSA https (CGI/1.1)
does not handle ";" params -- it thinks they are part of the path.;x=1;y=2?help

works (kind of), but;x=1;y=2?help

dies in a rather miserable fashion.

Add that to the list of things that need fixing. :(

......Roy Fielding   ICS Grad Student, University of California, Irvine  USA