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]

Reply via email to