Fwd: Re: HTML encoding in URLs

This WebDNA talk-list message is from

1997

It keeps the original formatting. numero = 14139
interpreted = N
texte = Ken Case from Omniweb has provided the explanation below, which makes sense, but doesn't make me feel any better. Just when I think I understand enough to do more than get by, along comes another weird one.Thanks for the prompt, professional and informative replies, Ken.RegardsThomas---------------- Begin Forwarded Message ----------------Date: 26/10 5:07 PMReceived: 26/10 5:13 PMFrom: Ken Case, kc@omnigroup.comTo: Thomas Wedderburn-Bisshop, thomas@woomeranet.com.auCC: WebCatalog Talk, WebDNA-Talk@smithmicro.comHi, just thought I'd provide a bit of clarification on that last message.> 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).Assuming it's properly terminated, that is. Say, with a semi-colon (which is ignored), or with another non-name character (such as =) which wouldn't be ignored.Netscape, unfortunately, doesn't require proper termination, so it translates entities whether or not they're terminated properly (e.g., a<b becomes a In other words, the following URL>> search>> should be interpreted as>> search>> Omniweb does this, then sends the interpreted string when I click on the> link, which of course confuses WebCatalog no end.Actually, OmniWeb only does this when our Netscape-compatible nonterminated entities preference is enabled. If it were a=1&ne=2, then the standard would indicate that we should translate the &ne (since it's properly terminated by an equals sign), but with a=1&neb=2 it's not properly terminated. (On the other hand, it's a good idea to always quote your ampersands as & if you don't mean for them to be interpreted as entities, since new entities may be defined as HTML evolves. For example, &ne was introduced with the HTML math entities proposal a few years ago, and is now part of the current HTML 4.0 proposal.)> Netscape does NOT do this interpretation in this case, and sends the URL> exactly as originally received.Netscape does not interpret &ne in any context, because it does not yet support math entities. It will in fact do the interpretation for any entities which it actually recognizes (such as <). So it appears they are trying to conform to the standard (although they do improperly translate entities which are not properly terminated), but don't yet have support for all the HTML 4.0 entities which OmniWeb supports.> Should we avoid anything that has &ne in it (or &eq, or &pi or....)? Should> I always make the link look like:>> searchAwkward as that is, that would be my advice. (In an ideal world, the ampersand character wouldn't have been chosen both as the HTML entity marker and the separator for form values in URLs.) Ken----------------- End Forwarded Message -----------------Thomas Wedderburn-BisshopDevelopment ManagerWoomera Net Solutions Associated Messages, from the most recent to the oldest:

Ken Case from Omniweb has provided the explanation below, which makes sense, but doesn't make me feel any better. Just when I think I understand enough to do more than get by, along comes another weird one.Thanks for the prompt, professional and informative replies, Ken.RegardsThomas---------------- Begin Forwarded Message ----------------Date: 26/10 5:07 PMReceived: 26/10 5:13 PMFrom: Ken Case, kc@omnigroup.comTo: Thomas Wedderburn-Bisshop, thomas@woomeranet.com.auCC: WebCatalog Talk, WebDNA-Talk@smithmicro.comHi, just thought I'd provide a bit of clarification on that last message.> 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).Assuming it's properly terminated, that is. Say, with a semi-colon (which is ignored), or with another non-name character (such as =) which wouldn't be ignored.Netscape, unfortunately, doesn't require proper termination, so it translates entities whether or not they're terminated properly (e.g., a<b becomes a In other words, the following URL>> search>> should be interpreted as>> search>> Omniweb does this, then sends the interpreted string when I click on the> link, which of course confuses WebCatalog no end.Actually, OmniWeb only does this when our Netscape-compatible nonterminated entities preference is enabled. If it were a=1&ne=2, then the standard would indicate that we should translate the &ne (since it's properly terminated by an equals sign), but with a=1&neb=2 it's not properly terminated. (On the other hand, it's a good idea to always quote your ampersands as & if you don't mean for them to be interpreted as entities, since new entities may be defined as HTML evolves. For example, &ne was introduced with the HTML math entities proposal a few years ago, and is now part of the current HTML 4.0 proposal.)> Netscape does NOT do this interpretation in this case, and sends the URL> exactly as originally received.Netscape does not interpret &ne in any context, because it does not yet support math entities. It will in fact do the interpretation for any entities which it actually recognizes (such as <). So it appears they are trying to conform to the standard (although they do improperly translate entities which are not properly terminated), but don't yet have support for all the HTML 4.0 entities which OmniWeb supports.> Should we avoid anything that has &ne in it (or &eq, or &pi or....)? Should> I always make the link look like:>> searchAwkward as that is, that would be my advice. (In an ideal world, the ampersand character wouldn't have been chosen both as the HTML entity marker and the separator for form values in URLs.) Ken----------------- End Forwarded Message -----------------Thomas Wedderburn-BisshopDevelopment ManagerWoomera Net Solutions Thomas Wedderburn-Bisshop

DOWNLOAD WEBDNA NOW!

Fwd: Re: HTML encoding in URLs

1997

Top Articles:

Related Readings: