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 _< >_