On Mit, 14 Apr 1999, Geoff Hutchison wrote:
>At 12:55 AM -0400 4/14/99, Fred Condo wrote:
>
>>I'm the originator of this bug report, and it occurs to me there are two
>>separate problems.
>
>Hi! I'm sorry I didn't realize you were on the list.
>
>>Htsearch generates and uses this, so it shouldn't be a big matter to
>>change the
>>separator. A quick check with the W3C validator shows that encoding the
>>ampersands as & validates under HTML 4.0 (strict) and works with Netscape
>>4.51.
>
>Hmm. If I understand you, the problem is that & should be used? Are all
>browsers going to send the correct & separator to the program?
Not necessarily. And they won't necessarily do it for a *very* long time.
As I review from our log files we have hits even with the most outdated
browsers in the world (Netscape 2.0, MSIE 2.1) and this will continue for
quite a while. Most of those who use the old browsers are from bigger
companies which do not regularly upgrade browsers - either because of
the costs for multiple licenses or because they got no one who's able
to install the browsers on their net (a lot of companies have maintainance
contracts and would have to pay a considerable amount of money to issue
a browser upgrade). Another thing might be that some browsers have been
discontinued for some OS which are still widely used (like OS/2).
>>CGI scripts, which are I would guess the principal users of the & separator.
>>But it's conceivable that there are still URLs that have & in them. I don't
>>know that there is any easy answer for this, unless the & solution noted
>>above is generally good.
>..
>AAt 3:16 AM -0400 4/14/99, Torsten Neuer wrote:
>>In fact the specs (6.4) refer to RFCs 1630 (URI) and 1808 (URL).
>>AFAIK CGI parameters and their respective separators are part of those.
>>IMHO W3C cannot change their meaning unless those RFCs are changed, too.
>>Furthermore this would lead to a complete incompatibility in *all*
>>CGI applications on the web, which cannot be a task of W3C.
>
>Yeah, I'm not sure & is going to work in all browsers, and the RFCs are
>pretty clear on the use of separators. I've also read those RFCs in regard
>to encoding and they're not clear on whether an SGML-encoded entity is
>legal in a URI. The *correct* URL encoding involves %nnn.
Yep. There is no SGML stuff in URLs or URIs.
>From my point of view there is no need to change the RFCs for URL/URI
as those should be put in quotes insed of HTML/SGML anyway.
Quotes on the other hand *are* special characters and should be issued
with their respective entity (not as some favourite WYSIWYG editors do
"as is").
That way any application could easily distinguish between & inside an
URL/URI (separating CGI parameters) and outside (starting SGML entities).
>That said, we still have to put SGML entity decoding into our URL code
>because some WYSIWYG editors insist on putting them in this way.
>
>-Geoff
>
>P.S. Any comment about "it's conceivable that there are still URLs" isn't
>met in reality. IMHO, there will be URLs with & in them for a *long* time
>to come. Just like the HTML parser has to deal with non-standard HTML,
>we'll have to deal with non-standard behavior.
Agreed.
cheers,
Torsten
--
InWise - Wirtschaftlich-Wissenschaftlicher Internet Service GmbH
Waldhofstra�e 14 Tel: +49-4101-403605
D-25474 Ellerbek Fax: +49-4101-403606
E-Mail: [EMAIL PROTECTED] Internet: http://www.inwise.de
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED] containing the single word "unsubscribe" in
the SUBJECT of the message.
