some HTTP functions error

[kosh]

## 1. Cannot restore context in (load "http://...")



for example...

Code Select Expand

newLISP v.10.2.1 on Win32 IPv4 UTF-8, execute 'newlisp -h' for more info.

> (print (get-url "http://gist.github.com/362201.txt"))
;; ...
(context 'MAIN)

> (context 'Foo)
Foo> (load "http://gist.github.com/362201.txt")
> (println "Context: " (context))
Context: MAIN                                 ; context changed!
>

> (reset true)

> (write-file "/tmp/test.lsp" (get-url "http://gist.github.com/362201.txt"))
> (context 'Foo)
Foo> (load "/tmp/test.lsp")
Foo> (println "Context: " (context))
Context: Foo                                    ; restore context
Foo>



## 2. (read-file "file:///C:/...") => "No such file or directory"

Code Select Expand

> (read-file "file:///C:/Program Files/newlisp/COPYING")
nil
> (sys-error)
(2 "No such file or directory")
> (read-file "file://C:/Program Files/newlisp/COPYING")
[text]
Copyright information...
[/text]


File URI scheme - http://en.wikipedia.org/wiki/File_URI_scheme#Windows_2">http://en.wikipedia.org/wiki/File_URI_scheme#Windows_2

Or for a local file, the hostname is omitted, but the slash is not (Note the third slash):



   file:///c:/path/to/the%20file.txt

[Lutz]

1.) After a 'load' the previous context should be restored after remote HTTP loads too. This will be fixed in 10.2.4. As a workaround use:

Code Select Expand


(eval-string (read-file "http://www.newlisp.org/context.lsp"))


2.) Currently newLISP strips of "file://" and uses the rest as a local filename to fee to the internal I/O functions. This makes for better compatibility of code when using the same code on Window and UNIX platforms and when changing ordinary path names to URI's, you only prepend "file://" on both platforms without the necessity to investigate if the path name on Windows starts with drive letter.



Although this is not strictly to spec, at least IE-Explorer and Firefox browsers also accept "file://c:/test.txt". I think the spec, how it is written is not practical, at least when looking at both UNIX and Windows platforms at the same time.



Perhaps we allow both file://c:/ and file:///c:/ on Windows



ps: funny that the forum software only formats the first form as URL, not the second form close to the RFC spec :)

[Ryon]

Oh no! I'm not touching the PHP!  :~O