Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Re: problems with url...(and another "escaped" problem)

From: gscottjones:mchsi at: 19-Jun-2002 9:34

Hi, Cyphre, From: "Cyphre"
<snip> > 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. %C8 being translated to "" occurs literally in the REBOL interpreter without further REBOL interaction. Witness (with artificial url for simplification):
>> http://a/%C8
== http://a/ 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 artificial url):
>> http://a/
== http://a/ 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 an escape! Later, the scheme wishes to check for the need for using a proxy: http-packet: reform [http-command either generic-proxy? [port/url] [target] http-version] 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 feedback? Hope this clarifies the additional mystery. --Scott Jones