On Thu, 23 Mar 2000, John McNally wrote:
> Thanks for the extensive list, but I am hoping there is some consensus
> amongst the various browsers about which characters they actually encode.
> It would appear that IE and Netscape both pass the % symbol unencoded.
As they well should, since otherwise there would be no way to pass any of
those nine special characters to a server.
> E.g if you want to pass the following string to mean discount=50% off $230
> <a href="http://host/servlet/Turbine/discount/50%230">
> And you count on the browser to do the conversion you are going to get
> discount=50#0
..which is what you just explicitly asked for. After all, it should be
obvious that you can't pass 50#0 in an URL without encoding it, since the
browser would just treat #0 as a fragment identifier and strip it off.
> However, if there are any browsers out there that actually encode the %
..then they are horribly broken.
> we encode on the server? I guess I will have to go look at the spec.
Yes you should. Just type "RFC 1738" into a search engine like Google.
It's actually a lot easier to understand than most of the "explanations"
out there, at least as far as section 2.2 is concerned.
> There is some ambiguity. You cannot encode a "/" and expect it to work.
There is none. The rules given in that section exist to remove any.
> having you send out the following path info: either fraction/1/2 or
> fraction/1%2f2 it is going to come back as fraction/1/2 because the browser
> is going to encode the / and not the %.
No browser should ever encode either, as they are metacharacters.
[utterly confused explanation stripped]
> on return and it is impossible to send fraction=1/2 as path info.
Your conclusion may well be true, and if it is, your webserver is to
blame. In theory, a %2F in a URL should be treated as a path component
with a literal slash in it. But it would appear that Apache decodes the
path part of an URL _before_ splitting it into components, or at least
does something else that gives the same effect. This is effectively a
server bug, although it probably doesn't explicitly violate any standards.
(After all, a server is free to interpret an URL any way it chooses.)
--
Ilmari Karonen
http://www.sci.fi/~iltzu/
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]