[REBOL] Re: problems with url...(and another "escaped" problem)
From: gscottjones:mchsi at: 19-Jun-2002 9:34
> PS: Some time ago I posted here "Generic proxy bug"
> problem but it seems nonone react on this thread,
> maybe it was overlooked. This should be simmilar
> problem but in proxy parser I think...so I repost it here:
I think that there are two separate things going on. They are similar in
that they both involve the escaped character sequence, but I think the
problems occur at different points.
being translated to "È" occurs literally in the REBOL interpreter
without further REBOL interaction. Witness (with artificial url for
The translation is "immediate." This suggests a big at the interpreter
level for url! (and same for file!, but the error is even less likely to
surface due to file naming conventions).
Other escape characters escape this immediate translation. Witness (with
The space escaped character remains escaped, and not translated. So then
why the difference with using proxy versus not using proxy?
The answer lies within the http scheme. At one point the "target" is
recreated out of components:
target: next mold to-file join (join "/" either found? port/path [port/path]
[""]) either found? port/target [port/target] [""]
Snooping around will show that port/target has already substitued a space
for the escape sequence; however, the to-file action retranslates it back to
Later, the scheme wishes to check for the need for using a proxy:
http-packet: reform [http-command either generic-proxy? [port/url] [target]
Here, the generic-proxy version utilizes the "spaced" version; whereas, the
non-proxy version uses the newly created escaped version (that is a path and
target only). A hacked fix would be sure that that the generic-proxy gets a
similarly re-escaped version, which could be done several ways, probably
most cleverly using Ingo's idea.
What I wonder is whether these 2 apparent bugs have been reported to
Hope this clarifies the additional mystery.