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:
auto-stripping of spaces (1997)
Country & Ship-to address & other fields ? (1997)
Multiple catalog databases and showcart (1997)
Trouble with formula.db (1997)
ooops...WebCatalog [FoundItems] Problem - LONG - (1997)
upgrade? (1997)
Emailer pref's won't save (2005)
Secure Server (1999)
Re:quit command on NT (1997)
setting taxable to true (1997)
Navigator 4.01 (1997)
Adding Shipping Costs based on percent of subtotal (1997)
Version f1 status (1997)
WebCat2 beta 11 - new prefs ... (1997)
Getting Values into Cart the easy way?* (1998)
Automatic POST arg sending? (1998)
WebCat2b14MacPlugIn - [include] doesn't hide the search string (1997)
Never Mind - Was - Credit Card Processing (2000)
[OT] installing binary app (2006)
Help! WebCat2 bug (1997)