According to Jerry Asher:
> I suspect the W3 recommendation is similar to their recommendation on
> maximum URL lengths: (rfc2068)
>
> >The HTTP protocol does not place any a priori limit on the length of a
> >URI. Servers MUST be able to handle the URI of any resource they serve,
> >and SHOULD be able to handle URIs of unbounded length if they provide
> >GET-based forms that could generate such URIs
>
> In other words, it's particular depending on your site's configuration:
> your server and the applications you are running. It doesn't affect
> anything outside of yor site.
Sure, as long as the bare ampersands are only used internally in your
site, or in CGI input from the client. However, if bare ampersands are
going out of your site in URIs in HTML to the client, as was the case
with htsearch before 3.1.5, then you're affecting something outside
your site contrary to the recommendations of the standard. That's why
htsearch had to be changed. We could have used "&" instead of the
semicolon, but we figured the pagelist was long enough already without
adding a couple hundred more characters to it.
...
> But I suspect it's not just AOLserver. Netcraft lists 38 different
> webservers with more than 5000 sites, and 53 webservers with more than 1000
> sites (and many many more with even smaller numbers.) Now it is true that
> the overwhelming vast majority of sites run either Apache, Netscape, or
> IIS, but there is certainly a healthy population of other webservers out
> there that may be conforming but not yet supporting the use of semi-colons.
But htsearch does correctly parse its own query string, so any web
server that supports the CGI standard shouldn't have a problem with
htsearch itself. If I'm not mistaken, the problem only arises when a
wrapper around htsearch depends on the web server to parse the query
string for it. When you pare down that list of 1000s of sites to only
those where the server does its own query parsing (I have no idea which
do and which don't) AND which use htsearch AND which use a wrapper script
around htsearch AND the wrapper script depends on the web server's query
parsing, then I suspect you're left with a pretty small subset.
I'm not suggesting that you yourself represent that subset, but given
that htdig 3.1.5 has been out for 15 months now, and you're the first
to report this particular problem, it doesn't seem like there's a whole
lot of users out there in the same boat. Up until now, all the griping
about the semicolon came from people upset at needing a one-line change
in their Perl or PHP wrapper script. That's why I asked for a good
argument for changing htsearch. Until now, I hadn't seen one.
...
> I believe the appropriate thing to do then is to make a configuration
> parameter that contains a string that defaults to ";" but that a site can
> change to anything (?) with the recommendation being "&"?
>
> I can make the patch, but my skills are mainly C and Java and Tcl. I see
> where I could brokenly hardcode some stuff into htsearch/Display.cc and it
> looks as though new configuration parameters are entered in
> htcommon/defaults.cc. Where else should I be looking?
In 3.1.5, you should also document the attribute in htdoc/attrs.html, and
reference it in htdoc/cf_byname.html and htdoc/cf_byprog.html. In 3.2.0b3
these files are automatically generated by running htdoc/cf_generate.pl,
based on the description in htcommon/defaults.cc.
There are many examples in htsearch/Display.cc of how to get and use
config attributes. You should use a String object to store it.
--
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
