AltME groups homeHelpJoin REBOL3 world

Recent posts

Worlds:r4wpr3wp
AccessibilityAbout / FAQ
Member's loungeContact/FeedbackOther REBOL links
Membership:
member name

password

Remember?

Not a member? Please join
10-May 6:23 UTC
[0.355] 28.421k
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

AltME groups: search

Find AltME posts
Help · search scripts · search articles · search mailing list

results summary

worldhits
r4wp5
r3wp125
total:130

results window for this page: [start: 101 end: 130]

world-name: r3wp

Group: !Cheyenne ... Discussions about the Cheyenne Web Server [web-public]
Davide:
3-Jan-2010
I would like to replace the tcp http server  with cheyenne.

Now I'm using a modified hipe server by Maarten Koopmans, but it's 
not async, so some things are currently not possible
Dockimbel:
22-Jan-2010
How about this scenario.. an on-message comes in, the code then does 
a 'read on an external server.. but the server takes 30 secs to respond.. 
does that blocK?


READ is a blocking operation, so it should not be used in Cheyenne 
main process (where ws apps run). Two possible solutions :


1) Use async HTTP with callbacks (I've proposed to include in Cheyenne 
the one I'm using currently for other products).

2) Send the READ job to a worker process using DO-TASK (but it will 
block it for 30secs, so not a very scalable solution).

I would use 1).
Dockimbel:
22-Jan-2010
Would you put a timer in the do-task/on-done func?


Not sure what you want to achieve precisely there. In your "READ 
quotes from remote server and send them every sec" scenario, I wouldn't 
use do-task, but async HTTP (much more efficient and scalable). I 
think I definitely need to add a few async schemes and make an example 
app.
Graham:
13-Feb-2010
POST /cgi-bin/rebdev HTTP/1.0
Accept: */*
Accept-Charset: utf-8
Host: host.rebol.net
User-Agent: REBOL
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 56


[0.4.0 "Graham" password  login]HTTP/1.1 500 Internal error in REBOL 
CGI Proxy
Date: Sun, 14 Feb 2010 02:05:45 GMT
Server: Apache/2.0.53 (Fedora)
Content-Type: text/plain; charset=UTF-8
Via: 1.1 bc7
Connection: close

Cannot connect (3)
Dockimbel:
11-Jul-2010
Graham: websocket is just an evolution of the HTTP protocol, it's 
not TCP, you can't contact a SMTP server from a browser directly 
if this is what you have in mind.
Endo:
11-Jul-2010
@Graham: you are using web sockets for a wierd job. The shortest 
explanaiton for web socket is: it is the way to trigger an event 
on the client side from the server side via already open tcp (http) 
connection. ofcourse that connection is full duplex, client and server 
both can send a utf8 encoded (currently no binary) string messages 
anytime.
GrahamC:
2-Dec-2010
This is what I am sending

HTTP/1.1 200 OK
Server: Cheyenne/0.9.20
Date: Thu, 02 Dec 2010 15:33:25 GMT
Content-Length: 475
Content-Type: application/vnd.adobe.xfdf
Connection: Keep-Alive
Content-Encoding: deflate
Set-Cookie: RSPSID=XESYTVZSEFSXPQHCTITGRDQG; path=/md; HttpOnly
Cache-Control: private, max-age=0
Expires: -1


Firefox opens up the PDF referenced in the xfdf file that is downloaded.

Chrome just downloads and saves the content.  So maybe it's just 
Chrome's PDF "plugin" that doesn't understand what to do ...
Dockimbel:
20-Apr-2011
No 404 here:
>> p: open/no-wait/direct tcp://localhost:80
>> insert p "DELETE /show.rsp HTTP/1.0^/^/"
>> probe copy p
{HTTP/1.1 200 OK
Server: Cheyenne/0.9.20
Date: Wed, 20 Apr 2011 11:06:16 GMT
Content-Length: 520
Content-Type: text/html
Connection: close
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: -1

<HTML>
<HEAD>
^-<TITLE>RSP Test Page</TITLE>
</HEAD>
...
onetom:
20-Apr-2011
onetom ~/rebol/delete $ cat httpd.cfg 
modules [ internal extapp static rsp alias ]
globals [ listen [8888]    bind RSP to [ .r ] ]
default [ debug root-dir %./ alias "/test" %test.r ]

onetom ~/rebol/delete $ cat test.r 
<% print request %>


onetom ~/rebol/delete $ rm chey-*.log; rebol -qws ~/rebol/cheyenne-server-read-only/Cheyenne/cheyenne.r 
-w 0 -vvv


onetom ~/rebol/delete $ curl -X DELETE -D- http://localhost:8888/test
HTTP/1.1 404 Not Found
Server: Cheyenne/0.9.20
Date: Wed, 20 Apr 2011 11:14:04 GMT
Content-Length: 53
Content-Type: text/html
Connection: close

<html><body><h1>404 Page not found</h1></body></html>


>> p: open/no-wait/direct tcp://localhost:8888
>>  insert p "DELETE /show.rsp HTTP/1.0^/^/"
>> probe copy p
{HTTP/1.1 404 Not Found
Server: Cheyenne/0.9.20
Date: Wed, 20 Apr 2011 11:17:34 GMT
Content-Length: 53
Content-Type: text/html
Connection: close

<html><body><h1>404 Page not found</h1></body></html>}



u were doing 1.0 DELETE request though, but it didn't make any difference.

onetom ~/rebol/cheyenne-server-read-only/Cheyenne $ svn up
U    mods/mod-action.r
Updated to revision 131.
Maxim:
22-Apr-2011
ok, so I promised a little announcement about work I have been doing 
in/with/for cheyenne...

I have built a web service module (mod) for cheyenne.
  -----------------------
  features/highlights
  -----------------------

   * extremely fine tuned to cause the least cpu hit on the server process 
   since ALL processing is done in worker processes.

   * it uses an arbitrary number of rebol script files which you assign 
   to any host in the config file. (even the default)

   * once assigned, these files are compiled dynamically (as one app) 
   by the mod and are exposed via http by the server.

   * only the functions you *chose* are *ever* visible on the web, allowing 
   you to include support libs, data and function right in your server-side 
   api.

   * no direct execution of code occurs, *ever* from the client to the 
   server, all input is marshaled, and parameters are typed to your 
   function specs.

   * allows ANY type of web api to be delivered, from REST to SOAP like 
   interfaces.

   * output is programmable, so that you can output AS  json, xml, html, 
   txt, etc.

   * interface is also programmable, so that you can provide GET params, 
   POST forms, POST (XML, JSON, REBOL native data)

   * Automatic API documentation via source scanning and function help 
   strings .  there will also be some form of comments which will be 
   used by documentation.

   * No suport for sessions. this is part of your application layer, 
   which should use https and session keys in the submitted data, if 
   you require it.

   * it takes litterally 5 minutes to convert your internal rebol code 
   into web services which obey internet standards.

   * System is auto-reconfiguring... i.e.  you don't need to close cheyenne 
   to update the service, just restart the workers.
Dockimbel:
29-Nov-2011
Btw, the embedded mode is for providing an HTTP server to an existing 
app, not a full-featured Cheyenne. If you want to make a GUI app 
in View for just a few simple interaction with Cheyenne, you can 
just #include your View code in %cheyenne.r.
Endo:
29-Nov-2011
Works great. Thank you!

the embedded mode is for providing an HTTP server to an existing 
app, not a full-featured Cheyenne
 But I can use RSP, websockets and webapps I think, right?
Dockimbel:
29-Nov-2011
As the (long) note explains it, it's a special API for closely integrating 
Cheyenne HTTP server with an existing app.
Group: !REBOL2 Releases ... Discuss 2.x releases [web-public]
BrianH:
2-Jan-2010
OK, now that we have 2.7.7 released (even though there is more work 
to do, i.e. platforms and the SDK), it is time to look ahead to 2.7.8 
- which is scheduled for release in one month on February 1. The 
primary goal of this release is to migrate to REBOL's new development 
infrastructure. This means:

- Migrating the RAMBO database to a new CureCode project and retiring 
RAMBO.

- Using Carl's generation code for the manual to regenerate the R2 
manual, so we can start to get to work updating it.

- Porting the chat client to R2 using the new functions and building 
a CHAT function into R2 similar to the R3 version.


The R2 chat client might be limited to the ASCII character set, though 
support for the Latin-1 character set might be possible. Still text 
mode for now, though if anyone wants to write a GUI client (Henrik?) 
we can put it on the official RT reb site accessible from the View 
desktop. The server is accessed through a simple RPC protocol and 
is designed to be easily scriptable.


It turns out that Carl already rewrote the installer for 2.7.something, 
but it was turned off because of a couple minor bugs that we were 
able to fix in 2.7.7. With any luck, only minor fixes to the registry 
usage will be needed and we'll be good to go.


As for the rest, it's up to you. Graham seems to have a good tweak 
to the http protocol, and others may want to contribute their fixes.
BrianH:
26-Mar-2010
Oh, I thought you meant here. And Doc writes a web server and networking 
protocols, Maarten has written a HTTP client (at least), and Gabriele 
has written other networking stuff. They're active.
Group: !REBOL3 Schemes ... Implementors guide [web-public]
BrianH:
5-Jan-2010
And there is no http server support yet.
BrianH:
5-Jan-2010
So, trying to port your http patches to R3? Funny, I was doing the 
same thing this evening. Wanna work together, or should I work on 
the reorg and server support instead?
BrianH:
5-Jan-2010
Sure. And it's going to be rewritten so that http server mode is 
supported too.
BrianH:
5-Jan-2010
Clarification: The http server mode is meant to be good enough for 
Doc to build an R3 Cheyenne on. If he feels the need to bypass it 
and go down to the tcp level, that would be a failure.
Graham:
6-Jan-2010
HEAD / HTTP/1.0
Accept: */*
Accept-Charset: utf-8
Host: www.rebol.com
User-Agent: REBOL

HTTP/1.1 200 OK
Date: Wed, 06 Jan 2010 07:28:08 GMT

Server: Apache/1.3.37 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 
mod_bwlimited/1.4 PHP/4.4.7 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.28 
OpenSSL/0.9.7a
Last-Modified: Fri, 01 Jan 2010 21:19:01 GMT
ETag: "3f44376-2667-4b3e66c5"
Accept-Ranges: bytes
Content-Type: text/html
Via: 1.1 bc1
Content-Length: 9831
Connection: close
Steeve:
6-Jan-2010
must initiate the path var to get a response from the server:
read [ scheme: 'http path: host: "www.rebol.com" method: 'head]

** Access error: protocol error: "Server error: HTTP/1.1 400 Bad 
Request"
BrianH:
24-Jan-2010
Chunked encoding is broken, which is why the released version has 
been modded to use http 1.0; error handling is broken (the source 
of most chat errors); no server support; written for an older idea 
of R3 semantics.
DideC:
26-May-2010
I want to build a very very very simple web server in R3.

I just want to be able to receive an HTTP request and send the response.
But me and Rebol networking are two differents people !!


To begin, I just want to be able to display the full request in the 
response page.

So far I have wrote this by peeking code in DocBase, but it does 
not work as I want : the browser stay awaiting the answer. Can one 
point me to what's wrong ?
DideC:
26-May-2010
REBOL []

print "Serving port 8080..."

open-subport: func [port] [
	print "=== Creating sub-port"
	port/awake: func [event /local port data] [
		print ["=== Subport event:" event/type]
		port: event/port
		switch/default event/type [
			read [
				print ["    " data: to-string port/data]
				data: replace/all data newline <br>

    write port to-binary rejoin ["HTTP/1.0 200 OK^/Content-type: text/html^/^/<html><head></head><body>" 
    data "</body></html>" newline]
			]
			wrote [
				close port
			]
		] [false]
	]
	
	read port
]

server: open tcp://:8080

server/awake: func [event] [
    print ["*** Server event:" event/type]
    if event/type = 'accept [
        open-subport first event/port
    ]
    false
]

wait 30
close server
print "Done serving"
halt
Group: !REBOL3 ... [web-public]
Pavel:
3-Dec-2010
An idea of NTP scheme, but servers comunicates only on 123 UDP port. 
overview of time services:

Daytime:  Ascii response,  Graham and Ladislav has written a scheme/tool 
already  port 13

Time: most simple possible server listening on port  37 answer 32bit 
unsigned number of second from 1-1-1900/0:00 (calculation of human 
readable date is not so trivial because of leaping seconds inserted 
to UTC with no rule at all, an Earth is dancing a Jive in fact)

HTTP: use inserted Date-time from any header returned from server 
port 80

SNTP: more precise protocol (contains also fraction of second in 
reply) subprotocol of NTP on UDP port 37

NTP: most precise available to compare more time servers, and calculate 
with computed transport delay and phase shift from evaluated couple 
of handshaking packets.  UDP port 37

The latter two use minimally 12  32bit binary packets for request 
and response, symmetric or asymetric cryptography possible (honestly 
I've no clue why this).
Group: !REBOL3 Modules ... Get help with R3's module system [web-public]
Gregg:
19-Jul-2010
From the loading modules doc: "...if a version number appears before 
any module name, it is assumed to be the REBOL system version.

  Needs: [3.0.2 mysql 2.3.0 http-server 1.0.1]

 Is there an explicit alternative? And how would you specify that 
 you need View or Command rather than Core?

And for checksums, would 
 it make sense to allow a keyword before the checksum, so you could 
 choose md5, sha1, or something else in the future? An unmarked binary 
 could still be sha1. I know it maps to the /check refinement on IMPORT 
 as well. I'm just thinking of implicit meaning versus long lifecycles.
Group: Core ... Discuss core issues [web-public]
james_nak:
12-Mar-2011
I think this is a Graham question. I've been trying to communicate 
with this video encoder. It uses .xml and .cgi files to talk to it:
tmp: http-tools http://192.168.1.62/user/GetTTLStatus.xml[]
and this works fine.


The problem is with he .cgi files. They aren't POST files but they 
only return 

 a: http-tools http://192.168.1.62/user/StorageMediaFiles.cgi[] probe 
 a
make object! [
    HTTP-Response: "<?xml version='1.0' encoding='ISO-8859-1' ?>"
    Date: none
    Server: none
    Last-Modified: none
    Accept-Ranges: none
    Content-Encoding: none
    Content-Type: none
    Content-Length: none
    Location: none
    Expires: none
    Referer: none
    Connection: none
    Set-Cookie: none
]
When you place the url in a browser it works as expected. 
Any ideas on how to get this to work?
james_nak:
12-Mar-2011
Graham,  I get an error 

Error.  Target url: http://192.168.1.62/user/StorageMediaFiles.cgi
could not be retrieved.  Server response: HTTP/1.1 40.... 
If you know a way to get the full error code, that might help.
james_nak:
12-Mar-2011
And you're right, there is probably something else going on. I am 
at least getting part of the message. A successful .xml call looks 
like this:

a: http-tools http://192.168.1.62/user/StorageEventMode.xml[] probe 
a
make object! [
    HTTP-Response: "HTTP/1.1 200 OK"
    Date: none
    Server: "Mango DSP - HTTP Server (v2.34)"
    Last-Modified: none
    Accept-Ranges: none
    Content-Encoding: none
    Content-Type: "text/xml"
    Content-Length: "270"
    Location: none
    Expires: none
    Referer: none
    Connection: none
    Set-Cookie: none
    Cache-Control: "no-store"
    content: {<?xml version="1.0" encoding="ISO-8859-1" ?>
<?xml-stylesheet type="text/xsl" href="StorageEventMode.xsl"?>
<StorageEventMode>
^-<RecOnNetworkFailure id="RecOnNetworkFailure" checked="true"/>
^-<PreEventBufferTime id="PreEventBufferTime" value="20"/>
</StorageEventMode>
}
]
james_nak:
12-Mar-2011
So what's happening is that the server is not returning an LF/CR 
to separate the contents from response fields so when it gets to 
 parse-header, that function does not know there is any contents. 
In stead of getthing something like:

HTTP-Response: HTTP/1.1 200 OK
Server: Mango DSP - HTTP Server (v2.34)
Content-Type: 
text/xml
Content-Length: 270
Cache-Control: no-store

<?xml version=
1.0" encoding="ISO-8859-1" ?>"

I am getting:

HTTP-Response: <?xml version='1.0' encoding='ISO-8859-1' ?>
<?xml-stylesheet type='text/xsl' href='StorageMediaFiles.xsl'?>
<StorageMediaFiles>
<MediaFile ..."


Placing a LF between the first and second lines fixes it. I am going 
to kludge it for now since I know what routines work and don't.
101 / 1301[2]