AltME groups: search

There's nothing specific you have to do on the web server side except 
providing the service interfaces (regular HTTP responses)

UniServe API documentation : http://www.softinnov.org/rebol/uni-guide.html

HTTP async client implementation : http://www.softinnov.org/tmp/HTTP-client.zip

set-cookie docs don't exist and it says n/a .. does this mean the 
word is not there any more or something else? Do I have to manually 
set http response headers to set cookies?

Set-cookie is on the todo list but hasn't been implemented yet. So, 
for now, you have to set http header manually.

I'm coming to the conclusion that any communication other than via 
HTTP is a waste of time. Sockets suck.

IMO HTTP sucks. Since years people try to make stateless HTPP stateful. 
One just needs a simple socket and than handle everything via a multiplexed 
channel system through this.

Well, HTTP works ok as long as you treat it like what it is: Stateless.

could there be any problem with running two cheyennes on different 
http ports on same computer ?

Logger service is for debugging messages btw, it doesn't handle HTTP 
logs.

I think you described it as "no longer HTTP" or something to that 
effect :)

The problem I've always had with Cheyene and Uniserve services was 
the 'disconnect' between the two.. ie: having a uniserve 'socket' 
connect with an 'http' connection and vice-versa.  The ws:// protocol 
was what i was looking for.. the best of both worlds. Deliver some 
hypertext, then push data to javascript in the browser.

Cheyenne is already doing such kind of "connections", for example, 
PHP requests : HTTP => Cheyenne => TCP => PHP server.

Some advantages to the ws:// spec

- Seamlessly traverse firewalls and routers
- Allow duly authorized cross-domain communication
- Integrate well with cookie-based authentication
- Integrate with existing HTTP load balancers
- Be compatible with binary data

The trick is that web sockets needs a little server support to down/upgrade 
(as you see it) a HTTP connection to a more flexible TCP connection

Though Comet and Ajax can both deliver end-user experiences that 
provide desktop-like functionality and low user-perceived latency, 
only Web Sockets lives up to the promise of providing a native means 
to accurately and efficiently stream events to and from the browser 
with negligible latency. It is by far the most comprehensive solution 
for delivering real-time information over the Web. Not only does 
it provide full asynchronous duplex streaming communication with 
a single TCP/IP connection, but also benefits from few HTTP headers 
and more importantly allows the same message format to be used by 
both the browser and the origin service.

It's the evolutionary endpoint of Comet. It throws in special server 
and client support to enable them to keep an open, stateful connection, 
by switching an HTTP connection to what is effectively a lower level 
TCP connection

It has a good chance of fooling the firewalls because it starts as 
a normal HTTP connection

As a continuous connection, it's less scalable than regular HTTP, 
yes, but it's more scalable than Comet, which needs two connections 
for bidirectional communication, and other hacks

after the initial http handshake, there's no http headers included

Here's a good primer

http://www.indicthreads.com/3625/html-5-websocket-cracks-the-http-request-response-barrier/

i still need to figure out how to interface incoming data frames 
with the RSP engine

That's where my Cheyenne websockets attempts hit the fan. Not so 
much the RSP, buf from a tcp socket to http and back again.

SVN r45 : Web Sockets support


FEAT: experimental Web Sockets support added. (See %www/ws.html and 
%www/ws.rsp)
FIX: regression on bad HTTP request filtering. (Thanks to sqlab)
FIX: minor code clean-ups.

WS.rsp  should look like this

<%

;-- RSP API web sockets specific changes --
;

;   request/web-socket? => true if this is an incoming socket message, 
false if it's HTTP.
;   request/content/data => contains the socket message (string!)

;-- just echo back the message
//prin request/content/data

inc: request/content/data
if inc = "makedrag" [prin "$('#test').draggable();"]  

if inc = "Hello World" [prin "alert('Hello back');"]
 
%>

I was looking at my old experiments.. and they date back to the pre 
Cheyenne, Uniserve days.

I simply created a traditional tcp socket to handle the tcp stuff, 
and Uniserve's http.r prot for http.

http uses data size

That comes from the way web socket's connection are initiated, it 
starts like a simple HTTP GET request and the server is supposed 
to validate that request, check access authorization if required, 
etc... So, to avoid duplicating work, I choose to re-use RSP framework 
as much as possible. The initial ws:// URL must point to a valid 
RSP script so that the server can check, for example, RSP session 
cookie for access rights.

My demo is ready, but I found an issue to fix first with HTTP keepalive 
connections timeout colliding with web sockets timeout. The demo 
should be ready to try in a couple of hours (lunch time here).

Web sockets server-side support code is much shorter than HTTP, so, 
in theory, it should scale higher.

SVN r52
FEAT: web socket realtime chat demo added.

FEAT: changed socket application's SEND function specs to SEND client 
[port!] data [string!] (/with removed).

FIX:  timeout web socket issue clashing with HTTP keepalive timeouts. 
Web socket ports are no more timed out after 15sec.

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

Now that there's a framework inside the main Cheyenne process, I'm 
considering adding more UniServe based implemented protocols to Cheyenne, 
like HTTP, POP3, IMAP and MySQL. There are of course all async.

HTTP is the most advanced, I use it in several apps in production. 
POP3 is beta. IMAP has just a few lines of code. MySQL is alpha, 
but working.

It's interesting... my browser hangs on it... so it's like it's not 
sending the http header to get things going.

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).

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.

I suppose having non-blocking async http and ssl, coupled with timers 
could make for a nice distributed system via ws:// . Could have clusters 
of Cheyenne :)

I want to move DevBase (R3 Chat) to Cheyenne, but I must admit that 
I am a newbie with Cheyenne.


Currently the code runs as a process, and we tunnel packets thru 
HTTP via Apache.


However, I could run it as a persistent process in Cheyenne, or via 
some method that would simply put the http input and output into 
a socket.

Anyone here know how this is done?

And is this a http timeout or a cheyenne timeout?

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)

Hmm.. Cheyenne is not handling HEAD correctly

>> read/custom  http://www.curecode.org/[ HEAD "" ]
URL Parse: none none www.curecode.org none none none
Net-log: ["Opening" "tcp" "for" "HTTP"]
connecting to: www.curecode.org
Net-log: {HEAD / HTTP/1.0
Accept: */*
Connection: close
User-Agent: REBOL View 2.7.6.3.1
Host: www.curecode.org
Referer: http://www.curecode.org/
}
Net-log: "HTTP/1.1 200 OK"
Net-log: ["low level read of " 2048 "bytes"]

this is with 9.19


>> read/custom  http://129.33.194.254:8080/tempsdfsfsadfasdfasf/hasfasdfsfpkkkk.pdf 
[ HEAD "" ]


URL Parse: none none 129.33.194.254 8080 tempsdfsfsadfasdfasf/ hasfasdfsfpkkkk.pdf
Net-log: ["Opening" "tcp" "for" "HTTP"]
connecting to: 129.33.194.254
Net-log: {HEAD /tempsdfsfsadfasdfasf/hasfasdfsfpkkkk.pdf HTTP/1.0
Accept: */*
Connection: close
User-Agent: REBOL View 2.7.6.3.1
Host: 129.33.194.254:8080

Referer: http://129.33.194.254:8080/tempsdfsfsadfasdfasf/hasfasdfsfpkkkk.pdf
}
Net-log: "HTTP/1.1 200 OK"
Net-log: ["low level read of " 2048 "bytes"]

Terry: short anwser: yes and no. Long answer: you should be more 
precise in your question. I guess that you're asking if a *single* 
Cheyenne instance can handle 10k concurrent connections on long lasting 
communications (HTTP keepalive or web sockets), the answer is : I 
don't know, I never tested that case. My guess is that if all clients 
are not sending requests simultaneously, Cheyenne should be able 
to handle it, but with a probably significant latency in the responses. 
For a real world web site, when dealing with short lasting requests, 
having a continuous load of 10k connections would mean that you're 
having a few million hits per hour making your web site one of the 
top 50 sites in the world, giving you enough money to invest in a 
huge cluster of servers to nicely handle the load with dozens of 
Cheyenne's instances ;-).

http://www.nginx.org/en/docs/http/configuring_https_servers.html

at the bottom talks about SNI support

I use something like this in my nginx config:
        location ~ \.(rsp|cgi)$ {
            proxy_pass   http://lucya.desajn.web:8080;
            
            proxy_set_header   X-Real-IP        $remote_addr;

            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
            proxy_set_header   X-URI $request_uri;

            proxy_set_header   if-modified-since $http_if_modified_since;
            
			client_max_body_size       10m;
            client_body_buffer_size    128k;

            proxy_connect_timeout      90;
            proxy_send_timeout         90;
            proxy_read_timeout         90;

            proxy_buffer_size          4k;
            proxy_buffers              4 32k;
            proxy_busy_buffers_size    64k;
            proxy_temp_file_write_size 64k;
        }

Oldes: would it help if X-Real-IP header was used by Cheyenne to 
store the real client IP in HTTP logs? I was thinking about addind 
an option to tell Cheyenne that a HTTP header is carrying the real 
IP.

I can access a websocket page from the interweb, but the socket communcations 
isn't working at all? However, it works fine accessing on the local 
network? Any ideas?

 Is there any HTTP proxy in between? Does it require SSL? Cheyenne 
 current websocket implementation doesn't support HTTPS yet.

 Is there any HTTP proxy in between? Does it require SSL?
 - No proxy, no ssl.

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.

@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.

yes when I paste it to the forum, all formatting goes out..
in http protocol scheme, pick takes just one argument, port.

oops, sorry, there is no "pick" in http.
it is in ftp.

Thanks for the code, but the handshake implementation was trivial. 
My current issue is the fact that the new ws draft is breaking HTTP 
specifications by using a GET request with a message body...WTF?

I'm not the only one to find that odd: http://blog.iworks.at/?/archives/69-WebSockets-Handshake-non-HTTP-conforming.html

re System logging service: it's not an option because :
- not a cross-platform solution

- some files *have* to be generated directly by Cheyenne (like the 
HTTP log file)

- the trace output in debug mode can generate huge entries that are 
inappropriate for syslog

- the trace output needs to be free from non-Cheyenne entries (or 
it might become unpractical to use for developers)

Still, I can't make Cheyenne work as non-root user : the HTTP log 
file keeps being written as root:root even if the main Cheyenne process 
is own by a non-root user. The culprit seems to be the REBOL helper 
process, forked by the main one during REBOL internal boot process 
(so before starting to run user code). I found no way to setuid this 
child process (seems forbidden by the OS?), so it keeps being owned 
by root...


Here's my typical test case under linux (Ubuntu 8.04, /enpro 2.7.6, 
latest SVN revision,using [user "dk"] in config file). I'm running 
the test from a root shell to avoid issues of sudo with REBOL binaries 
(RAMBO #4306) :

;--- launching  Cheyenne process  ---
[root-:-dknux]:/mnt/dev/Cheyenne# ./cheyenne &
[1] 20179


;--- notice the root process below (the only one that Cheyenne can't 
setuid( ) ---
[root-:-dknux]:~# ps aux
[...]

dk       20179  0.2  1.3   9028  6716 pts/0    S    22:21   0:00 
./cheyenne

root     20180  0.0  0.1   2360   600 pts/0    S    22:21   0:00 
./cheyenne

dk       20182  0.1  0.9   6264  4964 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20183  0.0  0.0   2184   236 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20184  0.1  0.9   6264  4964 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20185  0.0  0.0   2184   232 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20186  0.1  0.9   6264  4968 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20187  0.0  0.0   2184   236 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20188  0.1  0.9   6264  4964 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

dk       20189  0.0  0.0   2184   232 pts/0    S    22:21   0:00 
./cheyenne -l -worker 9799

;--- no HTTP log file for now ---
[root-:-dknux]:/mnt/dev/Cheyenne# ls -l log/
total 0

;--- I'm sending a request to http://localhost/---
[root-:-dknux]:/mnt/dev/Cheyenne# ls -l log/
total 1
-rw-r--r-- 1 root root 77 2010-09-09 18:19 default-access.log


The log file belongs to root:root, so it must have been generated 
by process 20180. Killing that process prevents Cheyenne from outputing 
any new log file (but Cheyenne keeps serving all requests). I thought 
that the helper process was only used for enabling async dns requests 
when OS doesn't support it natively?...<vent>Like REBOL GC's rules, 
this helper process remains a mystery even after 10 years of reboling...I 
guess these secrets are worth millions of $ to be kept undisclosed 
so far...</vent>

Any ideas?

SVN r96 -> r103 (most of new features were suggested by Carl)  


FEAT: encapped Cheyenne binaries now returns 0 (or, in case of panic, 
a REBOL error code) on exit

FEAT: (UNIX) Added a new command line option: -V or --version. Displays 
Cheyenne's version, then quits.

FEAT: (Windows) Cheyenne's version is now displayed in the tray icon 
help message.

FEAT: RSP debug mode extended to display tail of trace.log file using 
a new [show trace] button.

FEAT: RSP debug bar look improved, menu horizontal alignment fixed, 
direct link to RSP API online
documentation added.

FEAT: RSP errors are now displayed in an overlay popup instead of 
being inlined in the page.

FEAT: RSP debug bar javascript code footprint reduced to a single 
object: rspdbg (avoids polluting global namespace)

FEAT: new RSP API function: debug. Switches the debug mode on or 
off, for the current RSP script.

FEAT: new API function: debug?. Returns TRUE if debug mode is active.

FEAT: 'debug config keyword definition extended to accept an optional 
block of parameters.

FEAT: RSP session/start now returns the session/active? flag as result.

FEAT: (UNIX) Added a new boot option: -h or --help. Displays the 
command line syntax help and quits.

FEAT: Improved RSP function 'validate to accept default values for 
optional parameters when using
the /full refinement.

FEAT: now plain REBOL scripts can also be run by the RSP engine! 
(see www/show.r)

FEAT: new RSP API function: emit. Does a REDUCE on its argument before 
APPENDing to response/buffer.

FEAT: added new RSP syntax for emit-action : <%? ... %>. Does the 
same as 'emit, but inlined in a
template page.

FIX: (Windows) improved child processes termination with a more graceful 
method using JobObject API

FIX: (UNIX) optimized child processes termination using a kill() 
routine! wrapper instead of CALLing the shell command
FIX: flush HTTP logs in cache on exiting.

FIX: mod-userdir was still commented in config file modules list, 
disabling user/group keywords in httpd.cfg

More info on the new RSP functions in changelog.txt file.

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 ...

That is nothing which prevents ...

 ... there is nothing preventing anyone coming with networking protocols. 
 Yet r3 oficially supports only half-baked http :-) What I say is 
 - there is certain feature-list ... and product comparison table. 
 If RT decides to claim on their website - DLL interface for R2 is 
 not available, use more flexible Extension interface instead - fair 
 enough. But it is RT who owns the product, it is RT who defines its 
 features, and it is RT who needs to accept consequences - Doc stated, 
 why he will not port Cheyenne to R3, that is all ... and it is his 
 free will to state that ....

We look forward to that, seriously. But I at least understand that 
it is not appropriate to port it now. I hope to get advice from you 
about HTTP support in R3, when such advice is needed - that would 
be great :)

HTTP protocol is one of the simpliest Internet protocol to support, 
nothing that a skilled developer like you can't handle. :-) Anyway, 
I would be pleased to answer questions, as my free time permits.

my local script: 
<!DOCTYPE html>
<html>
<head>
  <style>img{ height: 100px; float: left; }</style>
  <script src="http://code.jquery.com/jquery-latest.js"></script>
</head>
<body>
	

<script>$.getJSON("http://localhost/jsontest.cgi”, function(data) 
{
      alert("JSON Data: " + data.foo);
});</script>
</body>
</html>

my rebol cgi script:
#!/cgi-bin/rebol.exe -cs %s %s
REBOL [Title: "json test"]
Print {
<html>
<head>
<title></title>

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

</head>
<body>
{
  "foo": "The quick brown fox jumps over the lazy dog.",
  "bar": "ABCDEFG",
  "baz": [52, 97]
}
</body>
</html>
}

I presume it's okay to start up cheyenne then load up my modified 
http protocol ?

Sure, you can load your custom HTTP protocol from your RSP code, 
or better, using the new "worker-libs" config block.

OTOH, that means each worker needs to load this ... might be easier 
for me to re-encap as the default http protocol

However, workers are only loaded once each and then reused, so your 
HTTP scheme will only be loaded the first time.

So, not only it stays in limbo, but it also blocks other requests 
that might be in the pipe coming through the same HTTP connection.

and this is the http request:  curl  -d '{"a": 1, "b": 2}' http://localhost:8080/?test

yes, the http connection will not close until it times out.


if the curl command line waits for ip close to return, its possible 
that is what is happening.

see the --http1.0 option above. with that there is no Connection: 
keep-alive  header sent  (or maybe there is, but in HTTP/1.0 mode 
it is ignored)

it shoudn't send it.  the servers are always free to implement more 
headers than the spec.

also realize that if you use http 1.0 there are no virtual hosts!! 
supported so its a bit deal.

hmm... does cheyenne handle the Expect: 100-continue header?

i couldn't really find any signs of it. the http-responses mentiones 
the code 100, but that's all, im afraid

HTTP code 100: not supported, if you have a (not obscure) use-case 
for that, I might add support for it.

onetom: DELETE is not supported by default, but it can be easily 
hacked in as you did (note to myself: add a config option to enable 
additional HTTP methods).

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 ~/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.

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.

Interesting ... I just Cheyenne for pure http and don't serve other 
web services yet

Cheyenne revision 134:

- FEAT: new config option (globals section): 'allow-method. Extends 
allowed HTTP methods.

- FEAT: -w command line option extended to allow to specify an additional 
"start" number value.

- FIX: -w 0 now starts Cheyenne with no workers at all (was spawning 
one at start until now).
- DOC: updated %changelog.txt (was lagging behind a bit).

See %changelog.txt for more info.

any drawback of using http digest, beside not being able to provide 
a nice login page?

http://www.berenddeboer.net/rest/authentication.html

this is a nice walkthru of the http auth theory with examples on 
how to do cross browser logout, forgotten password page, auto logout, 
etc etc

hmm... how can i map a directory under a certain path in vhost? im 
trying this:
yp [  root-dir %~/p/ob/yp  alias "/public" %../public/ ]

then for curl http://yp:8080/public/angular-0.9.15.min.js  i get

HTTP/1.1 301 Moved Permanently
Location: /public/angular-0.9.15.min.js/

wtf?

i remember seeing something like "/some/path" [ options ] in a vhost 
config block, but i can't find anything about it now

Means a 30x HTTP code was returned by the request.

onetom: sorry, I am not fluent in curl, I need to look for man pages 
for every options...Can't you use REBOL http client for testing?

$ cat jar
# Netscape HTTP Cookie File
# http://curl.haxx.se/rfc/cookie_spec.html
# This file was generated by libcurl! Edit at your own risk.


#HttpOnly_guan-huat     FALSE   /       FALSE   0       RSPSID  MTXVGMVOMYMVGDZKFURKPQKK

I'm using either REBOL HTTP client for testing or my own HTTP async 
client (using UniServe) that can handle cookies. But I never need 
to test my webapps programmatically (at least not so far).

When I need to debug an HTTP communication, I either look into Cheyenne 
reques/response logs or I use firebug.

Here how it goes with REBOL native HTTP client: http://piratepad.net/KkvkZ9AtME
 (see at bottom)

You should stick with REBOL HTTP client, using this patch to add 
transparent cookie support: http://www.rebol.org/view-script.r?script=my-http.r

my-http is nice though. i wish there would be a guide for all these 
protocol extensions.. there are a couple of half-baked versions of 
them... :/

pff.. my-http is not really transparent...

>> do http://www.rebol.org/download-a-script.r?script-name=my-http.r

connecting to: www.rebol.orgScript: "patched HTTP/HTTPS protocol 
with cookies support" (18-Aug-2006)
== none
>> trace/net on
>> read http://localhost:8080/testapp/login.rsp

URL Parse: none none localhost none testapp/ login.rsp** Script Error: 
querying has no value
** Near: http-command: either querying ["HEAD"] ["GET"]

my-http might not have been upgraded for latest REBOL versions.

Could you <Esc> the process and type: netstat? How many HTTP connection 
do you have?

Ok, so if you get a new "Connection closed", it means a new HTTP 
request was sent to Cheyenne.

because it always gets sent w all the http requests then, if it's 
stored in a cookie. so if u have images in the same domain(/folder) 
for example, then data is sent for those too

hmm... ok, i step back and think about it. thx, for ringing the complexity 
alarm! :)


on the other hand, i just saw there is https://github.com/nodejitsu/node-http-proxy
which is a reverse proxy for nodejs.

if u remember, i was missing this functionality from cheyenne too.


i think what carl was aiming w rebol is happening w javascript / 
json now...
it's not as advanced as rebol, though, but it's

Just one question, nothing urgent. Would it be possible or smart 
if cheyenne would return http 401 to ajax request when the session 
times out? Now it basically return 200 and login form html (so I 
have to test for presence of </form>) instead of usuall JSON.

So, if you could specify, for example: AUTH <http code> (instead 
of providing an URL), would it work with XHR?

In such case, Cheyenne would just return an HTTP code with no content 
and would let the client handle the redirection to login form (or 
whatever other action is suited).

as I say, it's not a practical problem for me. :) Just a suggestion.. 
I am making external API and I got some developers that are very 
sensitive to propper HTTP so I am rewriting my api to all those codes.. 
But this is not a problem for that, since API doesn't use cheyenne's 
sessions.. just while I am rewriting my ajax code I thought of it.

well .. you decide .. for me it's not a problem, really .. and I 
am also starting to think about HTTP codes now so I don't have the 
clearest view yet

Janko: I have extended AUTH to be able to return an HTTP code in 
revision 157:


FEAT: AUTH config keyword can now take an optional second parameter 
(HTTP code 4xx or 5xx) that will be returned to client instead of 
a redirection to the login URL.