Stas Bekman wrote: hi stas
i/we should probably spend our time on other stuff, but for the sake of argument ... :) > allan wrote: > >>so "/" is not a problem. > > > > why ? > > > > i can see that "/" (like "&") is reserved, thus should be > > escaped, no? > > not necessarily, you have quoted the explanation yourself: > > > 2.2. Reserved Characters > > > > Many URI include components consisting of or delimited > > by, certain > > special characters. These characters are called > > "reserved", since > > their usage within the URI component is limited to their reserved > > purpose. > > > If the data for a URI component would conflict > > with the reserved purpose, then the conflicting data must be > > escaped before forming the URI. > > Where in this URI :? conflicts with the reserved purpose? > > http://theoryx5.uwinnipeg.ca/cgi-bin/ppmserver?urn:/PPMServer > > To me everything after ? is a query string and can include anything at > all, as long as the browser doesn't have a problem with it. wrong (i think :)). how about "&", this should always be & even if every browser in the world understands the query, either you live up to a standard or you don't and you might end up in trouble in the future. i actually asked the question on the bbedit-list (my editor) and got this eleborate feedback ... <qouting> In this particular instance, BBEdit is doing more checking on the attribute value that the W3C validator, and issues additional errors when necessary. You should encode the / after the ? in the URL. In HTTP URIs, within the <path> and <searchpart> components, "/", ";", "?" are reserved. ? starts your search part, and / is no longer being used as a hierarchy delimiter afterwards, so you should encode it. A well behaved CGI will url decode the search part before doing work and all shall be well. There are some non-well behaved CGIs in existence, and that is unfortunate. (If you don't encode the / after the ? search part delimiter, a particular implementation is left to guess. It may guess that ? was part of a resource name, and that you forgot to encode it. In this case, you won't get the behavior that you desire. It may guess that the / after the ? was the thing you forgot to encode, and treat the ? as the delimiter between the path and the search part, in which case you will get the behavior you desire. But why leave it to chance when encoding the ? in the search part will remove the ambiguity.) </qouting> ./allan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
