According to Jerry Asher:
> Thank you. Interesting. I found the entry in the FAQ that points to the
> HTML 4 spec which sure enough "suggests" that webservers support semicolons
> and that applications use semicolons and not ampersands.
Yes, I decided to add that little bit to the FAQ entry this afternoon,
because I thought the added reference was overdue.
> I certainly don't want to get into an argument, but it appears from RFC
> 1866 section 8.1.2 that the ampersands are the standard and that semicolons
> are a nonstandard "encouragement" and this is backed up by the example POST
> submission shown in 8.2.4 (http://www.ics.uci.edu/pub/ietf/html/rfc1866.txt)
Well, call it a suggestion or encouragement if you like, but the fact that
it's in the appendix to a W3C standards document would lead me to conclude
that it's definitely not nonstandard. HTML is an evolving standard, but
if the W3C is encouraging us developers to follow that evolution, I think
we ought to.
> So I would still think that using ampersands is the standard, but since I
> am probably wrong, can you tell me why you believe that using ampersands is
> in fact non-standard and that semicolons are the standard (and as a founder
> of the opennsd webserver project, I would like to be able to convince my
> fellow opennsd developers that we should be supporting semicolons and
> deprecating ampersands/)
Well, there's no question that the ampersand is still the standard
separator for query strings passed via the Common Gateway Interface (CGI),
so any CGI program must still recognize it on input, as htsearch does.
However, the HTML 4.0 specification recommends a different standard
separator for query strings specified in URIs, so any conforming CGI
program should recognize that separator as well if it's to allow URI-based
query strings, as htsearch now also does.
I think the problem is the CGI standard was poorly thought-out as far as
the repercussions of using their choice of separator within URIs. The
W3C's recommendation of supporting a dual-standard like this is a good
way around it, and that's why, after much discussion almost two years ago,
we decided to adopt it.
To adopt this recommendation, though, we had to change the separator
used within URIs. Unfortunately, that means that when wrappers
around htsearch need to parse these URIs, they need to recognize the
new separator as well. It's a trivial change to a PHP or Perl wrapper
script, so it's not like we're asking a lot, but the resistance to the
idea has been rather surprising, so we've had to dredge up the debate
several times since the original discussion and decision.
> Since you note that it is open source, is it reasonable for me to think
> that if I submit a good quality patch that supports ampersands as well as
> semicolons, it will be applied to the source?
Well, I think it would take a good quality patch with documentation
changes to describe the new config attribute, plus a good argument
for why the change should be incorporated. I have yet to see one.
Making htsearch generate bad URIs for the sake of not having to make a
trivial change to your wrapper script just doesn't seem that wise to me.
--
Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil
Dept. Physiology, U. of Manitoba Phone: (204)789-3766
Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930
_______________________________________________
htdig-general mailing list <[EMAIL PROTECTED]>
To unsubscribe, send a message to <[EMAIL PROTECTED]> with a
subject of unsubscribe
FAQ: http://htdig.sourceforge.net/FAQ.html
