HTML encoding in URLs
This WebDNA talk-list message is from 1997
It keeps the original formatting.
numero = 14138
interpreted = N
texte = I was having trouble using an new browser (OmniWeb for Rhapsody) with WebCatalog, and I found what I thought was a bug in the browser, but Omni tells me it is the standard, in which case I am seriously confused about how to send parameters to Webcatalog in a standards-compliant way.The problem is (as stated in OmniWeb's post below) that URLs should be HTML-encoded, not ASCII. In other words, if something like &ne appears ANYWHERE in a HTML page, including inside the get string of a URL, it should be interpreted as ‚ (ie not equals). In other words, the following URL
searchshould be interpreted as
searchOmniweb does this, then sends the interpreted string when I click on the link, which of course confuses WebCatalog no end. Netscape does NOT do this interpretation in this case, and sends the URL exactly as originally received.I am sure OMNI knows what they are talking about (another case of Netscape ignoring the standards), but where does that leave us Webcatalog developers? Should we avoid anything that has &ne in it (or &eq, or &pi or....)? Should I always make the link look like:
search In the meantime I have turned off interpret unterminated special characters in omniweb, which fixes the problem.I am not a HTML expert, and would appreciate any suggestions here. Any HTML experts out there?Regards Thomas---------------- Begin Forwarded Message ---------------- Date: 26/10 1:28 PM Received: 26/10 1:32 PM From: Ken Case, kc@omnigroup.com To: Thomas Wedderburn-Bisshop, thomas@woomeranet.com.au> I'm not an expert on HTML, but I don't think it should be substituting > ANYTHING inside the URL, let alone unterminated entities. My understanding > is that if anything in the URL is encoded it should stay that way. Am I > wrong?I'm afraid you're misinformed: According to both the HTML standard and the behavior of all browsers, all HTML values (whether they contain URLs or not) are first scanned for entities (such as <) and those substitions are performed.I invite you to try the simple test of seeing what the following HTML does in IE or Netscape:
testYou'll find that all browsers turn that into the URL search?a=a<=lt. If the intent was to get the URL as written, the correct way to write it (in HTML) would be:
testYou'll find that every standard-following browser turns that into the URL search?a=a<=lt (which, of course, they wouldn't do correctly if they weren't doing the required entity substitution).The unfortunate thing is that & was picked early on as a separator for name-value pairs in a URL, when it also has a special meaning in the SGML reference character set (which HTML uses).Hope this helps! Ken----------------- End Forwarded Message -----------------Thomas Wedderburn-Bisshop Development Manager Woomera Net Solutions
Associated Messages, from the most recent to the oldest:
I was having trouble using an new browser (OmniWeb for Rhapsody) with WebCatalog, and I found what I thought was a bug in the browser, but Omni tells me it is the standard, in which case I am seriously confused about how to send parameters to Webcatalog in a standards-compliant way.The problem is (as stated in OmniWeb's post below) that URLs should be HTML-encoded, not ASCII. In other words, if something like &ne appears ANYWHERE in a HTML page, including inside the get string of a URL, it should be interpreted as ‚ (ie not equals). In other words, the following URL
searchshould be interpreted as
searchOmniweb does this, then sends the interpreted string when I click on the link, which of course confuses WebCatalog no end. Netscape does NOT do this interpretation in this case, and sends the URL exactly as originally received.I am sure OMNI knows what they are talking about (another case of Netscape ignoring the standards), but where does that leave us Webcatalog developers? Should we avoid anything that has &ne in it (or &eq, or &pi or....)? Should I always make the link look like:
search In the meantime I have turned off interpret unterminated special characters in omniweb, which fixes the problem.I am not a HTML expert, and would appreciate any suggestions here. Any HTML experts out there?Regards Thomas---------------- Begin Forwarded Message ---------------- Date: 26/10 1:28 PM Received: 26/10 1:32 PM From: Ken Case, kc@omnigroup.com To: Thomas Wedderburn-Bisshop, thomas@woomeranet.com.au> I'm not an expert on HTML, but I don't think it should be substituting > ANYTHING inside the URL, let alone unterminated entities. My understanding > is that if anything in the URL is encoded it should stay that way. Am I > wrong?I'm afraid you're misinformed: According to both the HTML standard and the behavior of all browsers, all HTML values (whether they contain URLs or not) are first scanned for entities (such as <) and those substitions are performed.I invite you to try the simple test of seeing what the following HTML does in IE or Netscape:
testYou'll find that all browsers turn that into the URL search?a=a<=lt. If the intent was to get the URL as written, the correct way to write it (in HTML) would be:
testYou'll find that every standard-following browser turns that into the URL search?a=a<=lt (which, of course, they wouldn't do correctly if they weren't doing the required entity substitution).The unfortunate thing is that & was picked early on as a separator for name-value pairs in a URL, when it also has a special meaning in the SGML reference character set (which HTML uses).Hope this helps! Ken----------------- End Forwarded Message -----------------Thomas Wedderburn-Bisshop Development Manager Woomera Net Solutions
Thomas Wedderburn-Bisshop
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
Web Catalog 2 demo (1997)
beta 5 - OS X install issue (2000)
Text limits in NT version? (1997)
I'm tired of all this! (2000)
can you take a look (2003)
Dates (1996)
Using Cookie for client specific info? (1997)
ErrorMessages.db (1998)
WebCatalog [FoundItems] Problem - LONG - (1997)
RE: Remote delivery (1998)
[include] (1998)
100% CPU (2003)
WebCat2 - [format thousands] (1997)
WCS Newbie question (1997)
WebCatalog can't find database (1997)
IE Cache Problems... (1999)
Separate SSL Server (1997)
User/pass with tcpconnect (2000)
Re:HTTP header line is too long? (1997)
Is this possible, WebCat2.0 and checkboxes (1997)