Hi Jan,

The patch to cope with the problem of "abnormal" relative URLs was
adopted to DeleGate/5.9.2, and it can be activated with the URICONV
parameter like this:

  URICONV=+ URICONV=normal


By the way ...

On 03/17/99(17:48) I wrote in <_A355@delegate-en.ML_>
 |On 03/08/99(23:35) you pjuaqbdyi-rn3efjmwkilr.ml@ml.delegate.org wrote
 |in <_A333@delegate-en.ML_>
 | | https://delegate.machine.edu/-_-http:/foo.edu/test.html
 | |and suppose that test.html has images of the form
 |...
 | |    <IMG SRC="../icons/picture2.gif">
 |...
 | |However, picture2.gif fails.  In the log, I see:
...
 |In your case the URL for picture2.gif seems wrong because it
 |points to outer space of WWW data of the server.  ".." means "upper
 |directory", of course, thus a relative URL points to upper directory
 |from a file at the top directory of WWW server is abnormal.
 |It should be one of the followings.
 |  "icons/picture2.gif"
 |  "/icons/picture2.gif"
 |  "./icons/picture2.gif"
 |
 |Then the client in this case interprets ".." in the URL to
 |normalize "a/b/../c" as "a/c", that is from
 |"/-_-http://foo.edu/../icons/picture2.gif" to
 |"/-_-http://icons/picture2.gif", then this is sent to DeleGate.
 |
 |This rewriting is a legal operation for a relative URL based on
 |RFC1808 (shown at the section 4.,step6,c).  And the RFC also
 |mentions about special handling of "abnormal" URLs like above, from
 |"http://foo.edu/" + "../icons/picture2.gif" to
 |"http://foo.edu/" + "icons/picture2.gif".
 |
 |Thus clients which implement the algorithm can access the target
 |resource with such abnormal, wrong URL.

I misread the specification.  It says that abnormal relative URL should
not be interpreted by client but should be passed to server as is.  If
your client program follows the specification, the reason why you can
access such abnormal URL without problem without DeleGate might be that
the server accepts "/../path" as if it is "/path".   This is possible
at least when the server is doing chroot() to the root of WWW data
directory, or the WWW root equals to root of the file system, because
".." from root directory points to root itself.

Thus I think the right way to cope with such abnormal URL in DeleGate
might be encoding abnormal ".." in response message to "%XX" or so
to prevent it from interpretation by client as normal URL when
accessed with /-_- notation or MOUNT mechanism of DeleGate.  If so,
I also must do decoding of encoded abnormal URL in request message
which seems not so simple...  So I will leave this problem until I
will find some problem which cannot be solved by "URICONV=normal".
(It is possible that some server accept "/../path" as a legal path
which must be distinguished from "/path"...) 

Cheers,
Yutaka
--
Yutaka Sato <ysato@etl.go.jp> http://www.etl.go.jp/~ysato/   @ @ 
Computer Science Division, Electrotechnical Laboratory      ( - )
1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan            _<   >_