AltME groups: search

http://www.downforeveryoneorjustme.com/http://www.red-lang.org/ says 
red site is down

Probably more like what they were intended to be in R3. (Does R3 
have anything besides HTTP support?)

I will provide the basic ones for Red: TCP, UDP, DNS, HTTP(S), SSL, 
SSH/SFTP, SMTP. Also, I would like to have a few more for remote 
or local storage builtin: Dropbox, MySQL, Postgresql. 


You are welcome to contribute other ones to that list (IMAP, SMTP, 
MongoDB, CouchDB would be nice additions).

:-)


File and network I/O: should be done for Christmas (maybe alpha state 
for networking). I will provide then HTTP client/server support shortly 
after. Expect more network protocols to come in Q1/Q2 2013. 2D/sound 
will be part of the work on GUI, so will happen later in 2013. Mysql 
support through networking: I will very much like to have that, as 
Postgresql support too. Expect them before summer 2013 (or maybe 
before for MySQL, if I need it for a killer Red demo). ;-)

Also, when asking for the file to be downloaded, you should rename 
the file to something more human-friendly or ask the name from the 
user. You can use Content-Disposition HTTP field for doing that easily. 
Here's an example from one of CureCode's RSP:

        response/buffer: get-modes file 'full-path	

        response/set-header 'Content-Disposition  rejoin [{filename="} name 
        {"}]

Just some additional notes to the Android release. It also contains 
the latest version of TLS scheme including supported ciphersuites. 
And there is updated HTTP/HTTPS scheme which should be more stable 
and handle network timeouts in better way.

I've temporarily rerouted our most important domains to our current 
IP address, so they work again, but they will break again when our 
network provider changes the address back.


Try REBOL works again, but it being half down allowed Graham and 
Andreas to find a bug in R3's HTTP handler. :-)

I wrote a quick & minimal example illustrating how to use R3-GUI 
together with R3's async HTTP:

https://gist.github.com/earl/447e4e9510a68c308f6b

Hi Doc, it is a great piece of code! Thanks a lot.
in readme file it says:

http://raw.github.com/dockimbel/printer-driver/master/printer-scheme.r

but it doesn't work. I think it should be https instead of http, 
then it works:

https://raw.github.com/dockimbel/printer-driver/master/printer-scheme.r

Note that my Etsy API script does patch HTTP (for purposes of retrieving 
API error messages).  You can view those changes here: http://reb4.me/r/etsy-http-hack.r

Andreas has pointed out that the http scheme uses several async handlers, 
and tcp level handler can create events to send to the outer http 
handler :(

R3GUI + async http...Nice demo Andreas!

Have you tried using Graham's http-tools? http://www.rebol.org/view-script.r?script=http-tools.r

Today I experimented with calling a REBOL script from my php script. 
Thanks to previous contributions of a.o. Ralph Roberts of abooks.com 
from 1999(!) and an entry on the PHP site I found out how to do this 
on my apache driven site.

It was not quite as straightforward as Robert said like: include 
("rebolnow.r");
Nor was it as simple as: system("rebolnow.r 2>&1", $myout);
echo $myout;

But it worked when I called out for the REBOL program first. Both 
two of the next examples worked for me:
system("/path/to/cgi-bin/rebol -c %rebolnow.r 2>&1", $myout);
echo $myout;
AND secondly
echo system("/path/to/cgi-bin/rebol -c %rebolnow.r");
Work!

The REBOL script must be in the same dir as your PHP script (Not 
in your cgi-bin directory)(I didn't test sub dirs and other dirs 
but I suppose they work like usual)
The script does not need the #!/path/to/rebol line at the top.
The script should not print http-headers and

When printing stuff the last line should read print "" because the 
last printed line will be repeated.

Hope this helps more people to switch from php scripting to REBOL 
scripting for their websites.

Amazon SWF holds the connection open for 60 seconds to allow events 
to appear.  This times out my http(s) connections though.  I tried 
setting system/schemes/timeout to 60 but that doesn't work??

Tried setting system/schemes/http/timeout too?

just using the default http scheme ....

this works, the other two do not

 system/schemes/default/timeout: 0:01:10
 ;system/schemes/http/timeout: 0:01:10
;system/schemes/https/timeout: 0:01:10

Uniserve task-master is mainly meant for server-side parallel request 
processing. For your need, you should use an async HTTP client rather, 
which would be a much simpler solution.

But, you should *really* use a async HTTP client, that's the best 
solution for your need (multiple HTTP downloads at the same time).

Sujoy: have a look at this description of  one of async HTTP clients 
available: http://stackoverflow.com/questions/1653969/rebol-multitasking-with-async-why-do-i-get-invalid-port-spec

I execute the following line and capture the HTTP packets using Capsa 
(or wireshark) I don't see any header information in the packets 
sent:
read/custom http://moldibi.com[header "X-hello:1"]


but when I run curl with same parameters, I can see the extra header 
information,
curl http://moldibi.com-H "X-hello:1"


does it mean I cannot add extra header information using REBOL or 
am I doing something wrong? (I'm using R2/View)

http://www.compkarori.co.nz:8000/Protocols/Http

 read URL [ header [ Cookie: "authtoken=anotherfoo" ]]

in default HTTP protocol or your version?

default http

from my page "NB: Rebol2's existing prot-http currently supports 
this undocumented method using a 'header keyword"  :)

@Sujoy .. there some relatively easy fixes to the R3 http protocol 
to handle this.  But .. due to various issues .. they just have not 
found their way into the binaries :(

Basically the http protocol sees a redirect eg. from http:// google 
to https google and complains.

Does anyone know if there is any problem with using a ":" within 
a http URL, for the *target* part of the path.   

as such, the URL doesn't have any relation to physical disk paths.

ex:

http://mydomain.com/stuff/group:resource

It seems to me that under Red, one marvelous tool which could be 
created would be similar this new one - which I just discovered ... 
at least with my not too long vision  - based on the Cheyenne HTTP 
server, it seems it could be realized using a similar approach, to 
begin with ... http://www.wakanda.org/overview- Also available 
on Github for those interested to look at the code (may be Topaz 
friends - sinc it is base entirely on Javascript).

http://www.rebol.net/wiki/Scheme:_HTTP

since this is the trace

HEAD /index.html HTTP/1.0
Accept: */*
Accept-Charset: utf-8
Host: www.rebol.com
User-Agent: REBOL

HTTP/1.1 200 OK
Date: Wed, 09 Jan 2013 09:03:18 GMT
Server: Apache
Last-Modified: Sat, 15 Dec 2012 07:02:21 GMT
Accept-Ranges: bytes
Content-Type: text/html
Via: 1.1 BC5-ACLD
Content-Length: 7407
Connection: close

>> write http://www.rebol.com/index.html[ HEAD ]
make object! [
    name: none
    size: none
    date: none
    type: 'file
    response-line: "HTTP/1.1 200 OK"
    response-parsed: none
    headers: make object! [
        Content-Length: "7407"
        Transfer-Encoding: none
        Last-Modified: "Sat, 15 Dec 2012 07:02:21 GMT"
        Date: "Wed, 09 Jan 2013 09:24:53 GMT"
        Server: "Apache"
        Accept-Ranges: "bytes"
        Content-Type: "text/html"
        Via: "1.1 BC5-ACLD"
        Connection: "close"
    ]
]

Gab, it says here that http 1.1 is partially supported http://www.rebol.net/docs/prot-http.html
 but you still pass 1.0

For me the value was not the transport layer but the integration 
and the structure of the messaing, service look up etc.


IMO we shouldn't use a HTTP only transport layer for R/S and this 
layer shouldn't be done on the mezz level.

We kept the http-error from Gab's prot-http.r until we figure out 
what to do about errors

Should get some concensus on this as it will affect all the schemes, 
and may need a little rewriting of the http scheme which uses write 
to pass options

On the http scheme, it could be the difference between adding a query 
string to a GET request (read/custom), and adding post data on a 
POST/PUT request (write).

Should we even use write in the http scheme?

Similarly most http write operations return a value of some kind.

so, the http scheme should stick to read for sync ops

A casual user of http, for sure : )

So, if you're reading a HTTP form, you can either use GET or POST 
 ....

the http scheme author has to then support both methods of doing 
the same thing

Graham, would you prefer have functions for all HTTP methods (get, 
post, put, delete, head, options, trace, connect) ?

Graham, HTTP GET is supposed to be repeatable without side effects, 
and thus safe to cache. HTTP POST is supposed to generate side effects, 
and thus not be safe to cache.

You have to see it in terms of the whole model. READ and WRITE don't 
just operate on HTTP and files, they can operate on a wide variety 
of port types.

An HTTP POST is not a read, for instance, it's more like a write 
because it is supposed to have side effects.

Where for HTTP (or my sandbox port example above), it is actual functionality 
that is lost.

SOAP's behavior is considered to be bad, as far as HTTP use is concerned.

Adrian, when make prep is run, prot-http.r is copied to host-init.r

tools/make-host-init.r is where the prot-http.r is included as well 
as all the others that are included into the binary

Graham, the TLS protocol scheme works transparently on tcp ports. 
So you just need to change the port/scheme from 'tcp to 'tls and 
you have the tcp connection secured. Then you can build any higher-level 
protocol over it. Having made the TLS scheme transparent I needed 
to make only few minor changes to the Gabriele's HTTP scheme to be 
able support HTTPS as well.

Are you talking about HTTP, the only scheme that has query and paths 
built into the URL spec standard? Because we have WRITE for that 
situation. For other schemes, we can define our own meaning of the 
query (and in some cases path) so we don't break the model.

There are more port actions than just WRITE and READ. Don't limit 
yourself to just those two. Most of the metadata operations for HTTP-like 
schemes are handled by QUERY.

Or they would be if the scheme were fully implemented, as the http 
scheme in R3 is not.

So, what should query do in the prot-http?

Where READ/args wins for me is that instead of, for example, composing 
a custom query string for HTTP -- you don't have to worry about that 
conversion. It's encoded and appended for you as defined by the port.

I have a PDF with the state diagram for HTTP, that may help you figure 
out the error problem. It's also possible that it was intentional 
in the sense that it is safer to initiate a new connection in case 
of error (though, some errors should be exceptions to this).

so possibly something in the http scheme object ?

The question of what to include by default is never easy, but can 
be guided to some extent by what is not just popular, but also has 
a well-defined standard that is useful. e.g. HTTP and FTP are standards, 
No-SQL is not. SQL92 is a standard, but is a strict SQL92 dialect 
useful?

OK, using that as a quality test, here's where the current SPLIT-PATH 
fails:
Path quality failed: %/ %/none
Path quality failed: %// %/
Path quality failed: %. %./none
Path quality failed: %./ %./none
Path quality failed: %./. %././
Path quality failed: %.. %../none
Path quality failed: %../ %../none
Path quality failed: %../.. %../../
Path quality failed: %foo/.. %foo/../
Path quality failed: %foo/. %foo/./
Path quality failed: %foo/../. %foo/.././
Path quality failed: http:// http:/
Path quality failed: http://..http://../
Path quality failed: http://.http://./
Path quality failed: http://../.http://.././

Must be -- + in the HTTP spec is escaped to a space at times. So 
i suspecet we're creating or receiving badly escaped URLs in this 
case.

http-tools is a good example.  I have some stuff, you have some stuff, 
there is A LOT of it here and there.

We've had a similar problem before (I've just checked the source 
code, and it's prompted my memory).


To solve it, we analyse the script for various extended ascii chars 
and then perform some messing around on HTTP content-type headers.


It's messy, and it's worked up til now......But obviously, we need 
some more analysing and messing around for this script.

note, I don't mean the http header, but the actual <HEAD> tag.

Maxim, REBOL.org emits a header

   <meta http-equiv="Content-Type" content="text/html;charset=utf-8">

Yeah, I know we aren't utf-8 -- but experiment has shown that's the 
moste acceptable charset.

Not sure what you are saying we could put in <head> -- can you be 
more specific.

there is a specific charset for western -iso, which ensure the extra 
127 bytes are correct.


<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">

I think the root of the problem is that when the Library system was 
first written, no account was taken of character encoding. As a result, 
not only is the data encoded as it was when originally submitted 
but the method of encoding is not even known.


Whatever charset is specified in the http header is not going to 
be correct for all scripts and messages. Using charset=utf8 seems 
to cause the least problems. Though for example, it will cause many 
ISO-8859-1 "high bit" characters to be incorrectly displayed.

Using Peter's code (thanks again!), I've made two changes to the 
download-a-script link:


1. if we find UTF-8 chars in a script, we download it with the HTTP 
content type charset=utf-8


But that probably makes no practical difference.  A downloaded script 
will be saved by the browser, and then opened by a text editor. The 
text editor is unlikey to be passed the charset setting. So:


2. Scripts with UTF-8 encoding are downloaded with a few lines of 
comment at their top. The comment explains the possible problem.


Thanks to all for the comments and help with getting things this 
far.

the browser prints "HTTP/1.0 200 OK" with .cgi

with trace/net on:

>> read http://192.168.1.27/cgi-bin/test.cgi
URL Parse: none none 192.168.1.27 none cgi-bin/ test.cgi
Net-log: ["Opening" "tcp" "for" "HTTP"]
connecting to: 192.168.1.27
Net-log: {GET /cgi-bin/test.cgi HTTP/1.0
Accept: */*
Connection: close
User-Agent: REBOL View 1.2.46.3.1
Host: 192.168.1.27
}
Net-log: "HTTP/1.0 200 OK"

and there it sits until I escape it

HELP w/ web rebol associations AND Rebol-View.
Here is the story..


On my PC, I have View pointing to an index.r file on my web server.
Everything is cool.

When I open up Rebol-View and traverse to my index.r on the server..
it works.


Now on the same server, I change the IIS-Web associations so that 
I can do rebol CGI.
I create a 'main.r' in some virtual directory on the server.
Web-ing to this http.//myserver/mydir/main.r   works GREAT!
CGI is working.


However, when I now open up Rebol-View on my local PC and traverse 
to my index.r which is
on the server.. I get an error.


The problem is that before.. rebol-view was requesting a file-download 
and the server sends it.

Now since IIS is doing '*.r' CGI, when rebol-view requests for the 
index.r download.. the server is processing the request
and attempting to send back html.. not a rebol file.


Is there any way of fixing this other than..

* changing the CGI association from '*.r' to something else  (ie. 
'*.rr')

* changing all my view-apps on the server from '*.r' to something 
else   (ie. '*.rr')
??

With Apache 2.x (normal CGI), we have: make object! [ 
	server-software: "Apache/2.0.54 (Fedora)" 
	server-name: "localhost" 
	gateway-interface: "CGI/1.1" 
	server-protocol: "HTTP/1.1" 
	server-port: "80" 
	request-method: "GET" 
	path-info: "/sample01.rhtml" 
	path-translated: "/var/www/html/sample01.rhtml" 
	script-name: "/cgi-bin/magic.cgi" 
	query-string: "" 
	remote-host: none 
	remote-addr: "127.0.0.1" 
	auth-type: none 
	remote-user: none 
	remote-ident: none 
	Content-Type: none 
	content-length: none 
	other-headers: [
		"HTTP_HOST" "localhost" 

  "HTTP_USER_AGENT" {Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) 
  Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6} 

  "HTTP_ACCEPT" {text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5} 
		"HTTP_ACCEPT_LANGUAGE" "en-us,en;q=0.5" 
		"HTTP_ACCEPT_ENCODING" "gzip,deflate" 
		"HTTP_ACCEPT_CHARSET" "ISO-8859-1,utf-8;q=0.7,*;q=0.7" 
		"HTTP_KEEP_ALIVE" "300" 
		"HTTP_CONNECTION" "keep-alive" 
		"HTTP_COOKIE" "PHPSESSID=7f84fd7766f23e1462fed550ecbbfda4"
	] 
]

But testing using http returns an error saying that rebol is not 
in the cgi-bin directory where it in fact is.

this is an article I wrote in 2003 hacking the http protocol to do 
this too http://www.compkarori.com/vanilla/display/HTTP+file+uploading

I don't know if it helps, but I did write a web server stress test 
that did a http upload of hundreds of images in Rebol that year.. 
but the scripts are long lost.

I used a variant of the http-tools.r script, composed the correct 
header, and then insert the headers, and then switched the port to 
binary before inserting the payload

Ok, I'll try to hack the http-tools.r, see if I can get anything 
done. I saw a script written in python claiming to do multipart uploads, 
but I hope I can get it working in Rebol, which for me is always 
first choice.

I played with Oldes script a bit, didn't get far. I think there's 
no other option than follow Graham's advice and delve in the http 
scheme. I had hoped to find something in the script archive, oh well... 
I saw that even in the Ruby and Python community there's some confusion 
on how to achieve multipart form submissions with CGI. (Python default 
http library also uses  "application/x-www-form-urlencoded" and not 
""multipart/form-data", but there's a library called HTTPFileUploader 
that does the job). Last time I tried to hack the http scheme I wasn't 
so succesful. This time, if I need help, I'll ask for help.

Graham described what needs to be done (I used a variant of the http-tools.r 
script, composed the correct header, and then insert the headers, 
and then switched the port to binary before inserting the payload). 
Only it's a little a bit above my capacities. In other words, I'll 
need two weeks to do it, if I ever manage it.

Graham, I'm a big fan of http-tools.r (I believe you wrote it,right?). 
I used it in my DYNdns client that I wrote in Rebol. I realized only 
recently that some of the functionality was built-in.(Basic authenticaion 
with read/custom). Grrrr... if only you hadn't thrown those upload 
scripts away :)

Daniel, I wrote http-tools.r before there was a read/custom .. that's 
how old the script is!

Yeah, I remember some tips you contributed to the rebolzine on posting 
to web forms, way back... Anyway, I think I won't tinker with the 
http scheme, kinda dpressing thought, especially since I have great 
hopes to achieve what I need using curl and the shell capability 
of Rebol. Let curl do that work, afte r all, that's what' it's meant 
to do best.

networking through the browser: you mean initiating HTTP requests 
for everything? that would slow performance waaay down.

Browser networking: I could be completely out of my mind, but I'm 
pretty sure that the browser sets up and tears down connections with 
each HTTP request. In other words, there's no "open connection" that 
we can just tap into -- the browser is initiating new requests for 
each page. To move to an architecture like that for plugin networking 
calls doesn't make much sense to me.......maybe I'm mis-understanding....

with browser - you can connect to whatever port too, no? It allows 
for url schema, so localhost:1234 is valid too .... just a http scheme, 
but ...

I am for domain restricting/sandboxing, not for features change, 
so that send would pop-up browser etc kind of things ... not sure 
it is manageable .... then reading http should use browser too?

It connect to a server application, like php-fastcgi or a REBOL FastCGI 
server built with /Command, or any other server accepting FastCGI 
clients. Then it sends the HTTP request and wait for a response back.

Will "Mike, I started using Apache and rebol as cgi, this is not 
suited for performances as on every call to the cgi, a new instance 
of rebol is  initialized, run and closed.

I thought about using fastcgi, but never came to a working solution.
Now I use uniserve as main webserver, here some advantages:

-it is fast! On my local machine I get +- 600 req/sec for static 
pages and a max of 160req/sec for dynamic rsp pages

-it is written in rebol, I could easly(less than 10 lines code) add 
a rewrite engine

-child process are persistent, this mean you can keep state of your 
web applications, implement caching, keep a pool of connection to 
databases open (in apache + rebol/cgi you'd have to open and close 
the connection for every request)
-it is written by Dock whom I may be the biggest fan ;-)

btw I'm running an unreleased version (have bought commercial support) 
 that support http 1.1, stuff like If-Modified etc..

If you have more specific questions, I'll be glad to try and answer."

does cheyenne handle http 1.0 and 1.1 transparently (expecting yes, 
but need a specific answer)?

HTTP support is stable, CGI are ok, RSP too, just avoid sessions 
for now. Next release will bring a complete rewrite of the session 
support for faster and more stable behaviour.

For Text RSP script I get:

Back

Timestamp: 


Request parameters :
HTTP Method: 
HTTP Port: 
Client IP address: 
Request headers :
Request variables :
Session :
SID: 
No session

REBOL/Plugin: yes, as any other HTTP client.

Does each http request spawn a new instance ?

Ajax is sending standard HTTP requests, so yes.

Can RSP pages retreive content using async http and return them to 
the client?

HTTP requests for static ressource are handled in multiplexing mode 
by the main Cheyenne process. Only CGI or RSP can currently spawn 
a new process if there's no free process available to handle the 
job.

I did so for my own server, which is an http web service:

R3 status update:
  240 kbytes
  57 data types
  71 actions
  124 natives
Missing so far
  async http
  security requestor
  unicode OS API 
Release dates:
  select developers 1-jan-2007
  primary developers 30-jun
  general developers: 15-jul