Date: Thu, 6 Oct 1994 03:14:27 +0100
Message-Id: <9410060159.AA17975@neon.mcom.com>
From: luotonen@neon.mcom.com (Ari Luotonen)
To: Multiple recipients of list <www-proxy@www0.cern.ch>
Subject: Re: Behavioural problem of cache/proxy (latest version)
Sorry Henrik, but the 3.0 proxy does work WRONG, and exactly for the
reason that you yourself explain below. It's true that having URL's
with '=' signs in them is not spec conformant either, but you
absolutely cannot "punish" them by working wrong yourself.
> The '=' _is_ a reserved character in the path according to
> the URL specifications in RFC1630
You are right. URL spec writer has reserved a right to later choose a
special meaning for '=', just like '?' and '/' have a special meaning
today.
What you don't seem to have understood is that in half a year this use
may be decided upon, and the proxy will end up having '=' signs that
stand for themselves and are used correctly, and the proxy ends up
escaping them.
There's one important rule when you're a proxy: DON'T EVER MESS WITH
THE URL. Don't care if it seems wrong, because the times may have
changed and you are an old version and don't know everything yet.
The URL spec tells the *document*providers* and *scripts* how to
escape a URL; once a client has a URL HREF it should be correctly
escaped, and the client must not touch it anymore. The same applies
to the proxy. If a proxy forwards a wrong URL it's the fault of the
*origin* of that URL. If the proxy modifies the URL it behaves dead
wrong.
*** The fundamental rule: ***
There exists no URL that is not correctly escaped when you are a
transfer or user agent. Only after the URL is mapped into the
physical resource inside a server/CGI program memory you may have
characters that are not standing for the special meaning in the URL.
But that isn't a URL anymore, that's internal representation of the
server, and no one ever sees it outside the server, because the moment
they go out, they must be turned into legal URLs, which means escaping
any illegal charcters.
I hope I cleared this misunderstanding now once and for all for
everybody. Fix it, Henrik! ;-)
Cheers,
-- Ari Luotonen Mosaic Communications Corp. 650 Castro Street, Suite 500 Mountain View, CA 94041, USA