AltME groups: search

Chris, the current http protocol does support custom headers with 
get like this 

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

Bug:

The old inconsistent bug of failing to copy the text of a message 
by simple right-click prevented me from copying Oldes' message with 
the long referrer link and cookie data in it, so I selected the message 
text first before right-click. That worked, but then all messages 
in the display began disappearing (looks like a shared para scroll 
bug). Even switching groups. Right now I'm looking at !AltME with 
several blank messages - only the dates appear normally.

The ultimate cookie

Read/custom allows you to send a custom header as in a cookie header 
like this

read/custom url [post "postdata" [Cookie: "name=value"]]

we can now do this


read/custom url [get  "dummy place holder" [Cookie: "name=value"]]

and this sends the cookie header with the get request

I would prefere to have an officialy inbuild transparent cookies 
support (as I prefere not to harcode every cookie request)

If you mean that the cookie is automatically captured by the http 
protocol, and then sent with every GET/POST, then that would imply 
you need to acquire the cookie first .. whereas sometimes you know 
what the cookie is and so don't need to get it first.

If you know the cookie, you can set it inside the cookies block, 
where are stored all cokies used for automated (transparent) sending. 
But I never used it. My clasic scenario is to simulate an user with 
the web browser. That means read page with login form, submit the 
form and do whatever like normal logged user. With some pages I can 
skip the first step, but there are pages which are giving you unike 
session ids in this step and don't let you login without this first 
step.

read/custom URL compose/deep [ PUT %file.png [ Cookie: (cookie) ]]


will use the http put method to upload a binary file and sets the 
cookie

Graham, in R3's http you can use any method you want, with any headers 
you want and any content you want. Was this your question? (I do 
still need to add transparent cookie support. but that's a few minutes 
work, so it'll be there for release.)

Something I'd forgotten ... but you can set custom headers using 
the header keyword.  Not documented though.

read/custom url [ header [ cookie: "blah blah" ]]

The header keyword is not needed if you do a post though.

Oldes, thanks. I get it. You one smart cookie. Gracias.

unless the cookie is corrupting it somehow.

The approach I have is that  every session has a cookie and disk 
storage associated to the cookie. When I define a web form, the action 
method gets a continuation id as a cgi parameter, so if at that point 
you clone the browser window, you as a user have to continuation 
ids

So basically the continuations are ensured by using both the cookie 
and associated storage and the continuation id that is added to the 
links as a cgi get parameter

read/custom - can it send more than one cookie at a time ?

well, working with cookies is not all that difficult, is it? My friend 
just asked me - why rebol does not handle sessions, if any other 
language does. I told him to write it himself, but he probably does 
not know how. Isn't session just about getting a cookie, looking 
into your storage space for the cookie identifier (session identifier), 
loading the session data, using them, and storing them once again?

you just need to parse system/options/cgi/other-headers iirc. see 
temple.cgi, it shouldn't have problems with that. (but if you have 
session handling you only need one cookie in the end).

Thanks C. It is really easy isn't it?

The main differences between your approach and mine that I can see 
are:
1. you hold all data in one file; mine uses one file per session

2. you create just a cookie; mine creates a session record in which 
the CGI script can save data

Either way, the scripts demonstrate that the problem is really trivial 
-- with the one need to create unique and hard-to-guess session ids. 
 We've both put some serious code into doing that.

Hmm, im using http-tools , I login to a page which sends a cookie 
which I then have to send back everytime, however the cookie seems 
to expire after one post :/

you normally need to send the cookie each time ... that's what browsers 
do

are you getting a redirect from the second page ... that is followed 
without the cookie

maybe it is just hidden, using cookies? If you have cookie, you are 
auto-logged-on, and the session will end when you close your browser 
session?

use the cookie-enabled http protocols on rebol.org (by Cyphre IIRC)

building the wget is trivial in rebol... but you still need the http 
calls to support cookies.  though we can probably probe the headers 
for cookie returns in newer R2 versions.

It can be used in similar ways that cross-frame with cross domain 
posting used to be, and of course there are some nice third party 
cookie tricks too.

The tracking works even you don't have FB account. They just don't 
know your name. But they have your IP and some info from cookies. 
For example :

Referer	http://domaci.ihned.cz/c1-48204850-brezina-proc-je-lepsi-dohoda-s-ods-nez-top-09-tak-vite-no-dali-nam-vyhodnejsi-nabidku

Cookie	datr=1250632065-19088ceda338e871e9ee01df712a37723a429d0d3c22849a1d7fc; 
lu=ThbkryR2mVGidAGoXhmTtO6A; presence=DJ289860316BchADhA_22106.channelH0_5dBF289860315007WMblcPBsndPBbloMbvtMctMsbPBtA_5b_5dBfAnullBuctMsA0QBblADacA9V289859900Z400K289859900QBalAD1O1171579986ADiA0QQQQ; 
cur_max_lag=20; x-referer=http%3A%2F%2Fwww.facebook.com%2Fpermalink.php%3Fstory_fbid%3D1573166021199%26id%3D1597009707%26notif_t%3Dwall%23%2Fhome.php; 
e=n; xs=2cf8155631bb0bfe623410554919f283; sid=60; sct=1289859896; 
c_user=1597009707
The FB's cookie life is 2 years.

I think that the REBOL http scheme should have cookie support that 
you can turn on or off (don't know which the default should be).

For instance, there isn't anything in the HTTP or URL standards that 
say that the path is necessarily a hierarchy, though the (poor) cookie 
standards definitely imply it. Ignoring the cookie standards, you 
could easily look at it as a tag list. However, you would need to 
be writing the server app to do so, since the server is what decides 
what the path means.

authors of various TryREBOL systems seem to have problem with persistence. 
Wouldn't Cheyenne be of some help here? By simple cookie you could 
identify the client and have one console session for him started. 
Cookie would expire at browser's end, or with zero activity for 15 
minutes for e.g. Is there anything I am missing here?

cookie demon ?

oldes so how do you made it to get the information where can i get 
your cookie deamon ?

Set the cookie to expire in 10 hours (log in once a day)

I associate the the IP with the user a well.. if the IP is a mismatch, 
the cookie is void

Terry: I'll provide an option in the next release to add session 
cookie expiration time, but will be "at your own risks" ;-).

how about regular cookie expiry?

Regular cookie expiry, it's up to the developer to handle that (the 
RSP 'set-cookie func is still pending).

Cheyenne release v0.9.15 beta. Download at http://softinnov.org/tmp/cheyenne-r0915.zip

Changelog :

v0.9.15 - 20/06/2007


 o RConsole was not started by default in the previous release. Fixed
	

 o RSP: 'include function protection from infinite cycles changed. 
 It's

   now based on a counter (5 maximum recursive includes). It's a little 
   less

   cleaner than stack-based tracking but much more reliable (avoids 
   matching
	  paths and targets).
	  

 o HTML.r library rewritten from scratch. Now, faster and more conforming 
 to 

   standards (Full range of Latin1 entities supported). Fixes URL-encode 
   bugs.

	o BugFix for command line parsing in encapped Cheyenne on Linux.
	

 o Fixed an issue with 'decode-multipart in RSP.r. File upload should 
 work ok 
	  again.
	  

 o Added a new global function : 'rsp-log value. Outputs values in 
 console for 
	  debugging RSP scripts. Works as 'probe.
	  

 o Reloading config file now supported. Running sessions and client 
 connections

   survive to the reloading process (needs some additional testing). 
   Activating
	  config file reload is done using:
	  
	  		- (Windows) "Reload Config" menu option in systray icon.
	  		- (UNIX)     kill -s HUP pid
	  		

 o UNIX signals SIGINT,SIGQUIT,SIGTERM now catched to allow cleaner 
 exit and last

   minute actions. Triggers the new 'on-quit event for HTTPd modules.
	

 o HTTPd internal events (not phases) refactored to be cleaner. New 
 module's
	  events added:
	
			- 'on-started:	when Cheyenne starts.
			- 'on-reload:   before a config file reload happens.
			- 'on-reloaded: after a config file reload happens.
			- 'on-quit:     when Cheyenne is about to stop and quit.
			

 o RSP sessions can now be made persistent (can survive to a server 
 complete restart).

   This option is controlled by a new config keyword: 'persist. Usage 
   is :
	  	
	        persist [sessions]    ; other flags can be added at will
	        

 o BugFix in session cookie handling for web-apps using 'auth mode. 
 Now the cookie

   is sent on the 302 redirection to the login page avoiding the creation 
   of a 
	  "shadow session" that will never be used. 
	  

 o FastCGI is under heavy work so mod-fastcgi is commented in config 
 file to avoid

   fastcgi startup. If you want to play with PHP, just uncomment the 
   line.

We've got server side cookie handling, session support, db  ( mysql, 
postgresql ) and web server

A good starting point for doc links is http://www.erlang.org/doc.html
.


The pros are that it's been around for a long time, it was built 
to solve a specific type of problem, and has been proven to work 
for large commercial systems. It also has a nice community it seems. 


Just as C# and VB.net are capable languages, you really need to know 
the .NET framework to make things sing. Erlang, by itself, is very 
capable, but the OTP (Open Telecom Platform) provides a huge amount 
of value on top of it, if you're building distributed systems. It 
also has Yaws, Ejabberd, and other things already built that you 
can leverage.


On the downside, it's a very different model that takes some getting 
used to, though Maarten got up to speed for experimentation very 
quickly. If you're used to Prolog, that will help. It's also really 
only good for back end stuff, so we would still be doing front ends 
in something else, which wasn't the dealbreaker in our case. What 
turned us away was the security model. It's designed for use in an 
intranet type (read safe) environment, where access to machines on 
the cluster is controlled by secret cookie. If your cookie is compromised, 
they have absolute power over the node, and any nodes it shares that 
cookie with.  http://www.erlang.org/doc/reference_manual/distributed.html#11.7


We decided that, since we would end up building security on top of 
everything, using something like dialects for control, we were better 
off sticking with REBOL. There are a number of things out there already 
to bulid on (LNS, Rugby, Uniserve, BEER), we can really do things 
the way we want, in a tool we know we like and are comfortable with. 
And we know its limitations, so there will be fewer surprises.

Maarten, yes you can set the secret cookie but if one system is compromised 
the whole distributed system is. how is that different in other architectures 
?

I think Cheyenne's webapps are protected by cookie authentication

I see req/in/headers/Cookie gets the cookie, but setting it how?

Can set with javascript 
<script>

document.cookie ='cheyenne=testcookie; expires=Thu, 15 Oct 2008 20:47:11 
UTC; path=/'
</script>

the biggest blockage in developing learning was just now when I was 
making login function and it stopped setting cookie, it took me at 
least half an hour looking at the code and then I discovered I disabled 
cookies by accident in FF webdev toolbar :)

New Cheyenne test release 0.9.19 available. Please report any bug 
or regresson here.

Changelog (diff from previous one) :


  o RSP: fixed a security issue allowing access to /webapp/private/ 
  sub-folders content.
	 

  o RSP/CGI: fix for HTTP 'Date header not being returned in some cases.(Will)
	 

  o RSP Sessions: fixed an issue with init flag when saving sessions 
  on disk.(Will)
	 
	 o RSP: now you can declare folders as valid login URL.(Will)
	 
	 	Ex: auth "/admin/login/"
	 	

  o RSP: a new session word 'from has been added. It's set to the referring 
  URL on login.

    After login, you can now redirect to the referring page (in case 
    of session timeouts
	   for example).(Will)
	   

  o RSP: a webapp can now be called without the ending slash.(Will)
	 

  o RSP: the root "/" webapp can now be declared (needs testing).(Will)
	 	 

  o RSP: new 'SID-domain config keyword added allowing to share sessions 
  between
	   sub-domains.(Will)
	 

  o RSP: now session ID can be passed as URL or POST data in addition 
  to cookie.(Will)
	 

  o New 'charset config keyword added. It allows to define specific 
  charset sent through
	   HTTP headers for 'text/htlm resources.(Will)
	   

  o RSP: Added a new function no-log in Response object. Use it to 
  avoid writing
	   log info to disk for the current request.(Will)
	   
	   		Ex: response/no-log


  o New 'mod-expire module for HTTPd. Allow configuring 'Expires HTTP 
  header. 
	   See %Cheyenne/mods/mod-expire.r for more info.(Will)

Before setting-up the reverse-proxy config so that I can use cheyenne 
with all RSP features I have some questions:


1. Session handling: I understand that sessions can now be used via 
cookie, URL-parameter or POST data. How do I select which method 
to use? Can I start with Cookies and if this fails (can this be detected?) 
fall back to the other methods?

1. When first accessed, a RSP web application will send you a session 
ID by cookie. You can send it back by cookie or included in GET or 
POST data. If you want your session ID passed inside the HTML page 
in all URLs, you have to add it in your RSP source using some code 
like : rejoin ["RSPSID=" session/id].

1. "You can send it back by cookie or included in GET or POST data." 
Well, my understanding is that the YOU here refers to the delivered 
page. So, the page needs to be prepared a priori to delivering with 
either the session-id etc.

But if I do this, I won't need a cookie at all.


So, I first need to check if cookies work? Is there a simple test 
function in RSP like: COOKIES-AVAILABLE?

3. Blocks: That's the way I want to go. Using the session ID to store 
shopping-carts. And than a clean-out run after several days or so.


The problem with the session-ID not being a cookie is, that the session 
is lost if the user closes the browser and later returns. Right?

1. Good point. You need to use the session/active? to test if a session 
has been automatically created, if not, that means no cookie support 
(require to serve a RSP page first, then check on the next call to 
a RSP page, an HTTP redirection might help you do so). Then, you 
can use session/start to manually start the session and send back 
the SID.

3. Ok. So, if the browser window is closed, the session cookie will 
be deleted? Or will the session survive a window close if the client 
accepts cookies?

Yes, that's my understanding as well. That's why I want to cross-check 
what kind the session-ID cookie in Cheyenne is.

The cookie setter can specify a deletion date, in which case the 
cookie will be removed on that date. If the cookie setter does not 
specify a date, the cookie is removed once the user quits his or 
her browser.

just wanted to drop by and say that I published alpha of my first 
mini cheyenne webapp and it is the most responsive app I ever made 
.. it is noted also when not on local comp and someone of 2 peps 
that tried it already wondered how come it loads so fast ...  this 
is minimal app so it looks more reasonable but I know a slightly 
bigger app that I am making behaves just as fast for now..  have 
to run.. will read this cookie discussion other time

From faq:

A webapp is a directory in the webspace which is protected by an 
authentication cookie. It is specified inside the httpd.cfg, where 
there is a sample "testapp".

And how is the authentification cookie made, sent, ...?

A session is a block! of name / value pairs that is kept in Cheyenne's 
main process and exchanged with worker process. A synchronization 
system is there to avoid concurrency issues. The SID sent by cookie 
to the client is just a lookup key. When sent back to the server, 
this key allows to identify the right session object to pass to the 
RSP script in a worker process.


You are only limited by memory, but remember that the session object 
is MOLDed / LOADed and exchanged by TCP twice for a RSP request. 
So, in order to keep your RSP pages fast enough and scale well with 
a growing number of active users, keep the session block! as small 
as possible.

If you want to access a web app from Rebol

page: open login-url ; a rsp session is sent to you
page/locals/headers/set-cookie contains the cookie

page: read/custom login-url compose/deep [ POST (auth) [ cookie: 
(cookie)]] ; where auth is your authentication string eg. "login=user&pass=mypassword"
you are now authenticated
and if you now what to access a page in the web app

page: read/custom web-app-url compose/deep [ GET "" [ cookie: (cookie)]]


where you need to use my modified http protocol that allows you to 
send cookies with read/custom

Web-Apps Login: Is basic authentication supported? I have a situation 
where form-and-cookie authentication is awkward.

Same as session cookie : RSPSID

yes, dialect based solution would be very interesting ... I was thinking 
about dialects a little too (not concrete yet) ... currently my testing 
engine is made so that it uses a proxy and it records your what you 
do via browser and then it can repeat the same and comparte the output 
(it already figures out that it needs to set different cookie and 
some basic stuff to login for example , and I have idea to make it 
scriptable for other dynamic data but I haven't come that far yet 
) . It also doesn't do any smart comparisson of the outputs, but 
more of a report for human to view for now

actually the resource url is already saved when a session timeout, 
this is the code in mod-rsp.r:
req/out/code: 302
					sessions/set-cookie sess req
					h-store req/out/headers 'Location url
					h-store req/out/headers 'Last-Modified none
					repend sess/vars ['from req/in/url]
					throw true 	; redirects to login page

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Date: Wed, 19 Aug 2009 07:41:04 GMT
Expires: Wed, 19 Aug 2009 07:41:04 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
Server: GFE/2.0
Via: 1.1 bc3
Content-Length: 0
Connection: Keep-Alive
Set-Cookie: cookies here ... 

Set-Cookie: user=; Expires=Tue, 18-Aug-2009 07:41:04 GMT; Path=/; 
HttpOnly

Set-Cookie: login=; Expires=Tue, 18-Aug-2009 07:41:04 GMT; Path=/; 
HttpOnly

why do u have Content-Length: 0 ?
this is not valid Set-Cookie: cookies here ...

this is the request


GET /md/creategoogledoc.rsp?gdoc=simple-letter.rtf&patientid=2832&encounter=none 
HTTP/1.1
Host: gchiu.no-ip.biz:8000

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.2) 
Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://gchiu.no-ip.biz:8000/md/Listgoogledocs.rsp
Cookie: RSPSID=QZPTPCZIWWMMYBKWHWRQETGM

ok here is the answer from Cheyenne:
HTTP/1.1 301 Moved Permanently
Server: Cheyenne/0.9.20
Date: Thu, 20 Aug 2009 09:43:23 GMT
Connection: close

Location: http://docs.google.com/Doc?docid=0AcdrOHdpKfrWZGZwd3Z4MmJfMnNxcDJkNmZu&hl=en
Set-Cookie: RSPSID=OTWARJZIFLZYABVJOACFFTZY; path=/md; HttpOnly

answer from the redirection:
HTTP/1.1 302 Moved Temporarily
Content-Type: text/html; charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Date: Wed, 19 Aug 2009 21:43:58 GMT

Set-Cookie: WRITELY_UID=001dfpwvx2b|928b9de9e7bf56448b665282fc69988b; 
Path=/; HttpOnly

Set-Cookie: GDS_PREF=hl=en;Expires=Sat, 17-Aug-2019 21:43:58 GMT;HttpOnly

Set-Cookie: SID=DQAAAHcAAAB0kldc4zZSC_0FoiL6efkWE11k9SQkAIn-N3WfAzIOVe1cM-remnLUtV3Z4M-BFRf5eknz7hr_U3YzW94nECo0-aDnpxrLGiBglWGN4VkfLr5Hh7t2XNyRCA3VWd005SfCmZ9D8-1MUltjRI8X56VLde5Wy8HD92gh-8YkJBJxQA;Domain=.google.com;Path=/;Expires=Sat, 
17-Aug-2019 21:43:58 GMT

Location: https://www.google.com/accounts/ServiceLogin?service=writely&passive=true&nui=1&continue=http%3A%2F%2Fdocs.google.com%2FDoc%3Fdocid%3D0AcdrOHdpKfrWZGZwd3Z4MmJfMnNxcDJkNmZu%26amp%3Bhl%3Den&followup=http%3A%2F%2Fdocs.google.com%2FDoc%3Fdocid%3D0AcdrOHdpKfrWZGZwd3Z4MmJfMnNxcDJkNmZu%26amp%3Bhl%3Den&ltmpl=homepage&rm=false
Content-Encoding: gzip
X-Content-Type-Options: nosniff
Content-Length: 325
Server: GFE/2.0

more redirection:
HTTP/1.1 302 Moved Temporarily

Set-Cookie: WRITELY_SID=DQAAAHoAAADh80lBIw7e5Hg06TLEBgCY33XQGJ1aUH5OrCF_ir1xLwffKNaCqNdUL6qYfvgjNppDBI4lTNBSTjJWMG_Ze0_qJnveBCAtihBDFwBlOb-H7RlkfgJwM7pBbyKV7bm4M3mqUivD1emtpxgl32vG8CEP1poQ2479HQXrlobsp7Egzw;Domain=docs.google.com;Path=/;Expires=Thu, 
03-Sep-2009 21:43:59 GMT

Location: http://docs.google.com/Doc?docid=0AcdrOHdpKfrWZGZwd3Z4MmJfMnNxcDJkNmZu&amp%3Bhl=en&pli=1
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Date: Wed, 19 Aug 2009 21:43:59 GMT
Expires: Wed, 19 Aug 2009 21:43:59 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
Content-Length: 232
Server: GFE/2.0

and the the target page:
HTTP/1.1 200 OK

Set-Cookie: WRITELY_SID=DQAAAHoAAADh80lBIw7e5Hg06TLEBgCY33XQGJ1aUH5OrCF_ir1xLwffKNaCqNdUL6qYfvgjNppDBI4lTNBSTjJWMG_Ze0_qJnveBCAtihBDFwBlOb-H7RlkfgJwM7pBbyKV7bm4M3mqUivD1emtpxgl32vG8CEP1poQ2479HQXrlobsp7Egzw;Domain=docs.google.com;Path=/;Expires=Thu, 
03-Sep-2009 21:43:59 GMT

Set-Cookie: GDS_PREF=hl=en;Expires=Sat, 17-Aug-2019 21:43:59 GMT;HttpOnly

Set-Cookie: user=; Expires=Tue, 18-Aug-2009 21:43:59 GMT; Path=/; 
HttpOnly

Set-Cookie: login=; Expires=Tue, 18-Aug-2009 21:43:59 GMT; Path=/; 
HttpOnly
Content-Type: text/html; charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Date: Wed, 19 Aug 2009 21:43:59 GMT
Content-Encoding: gzip
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
Server: GFE/2.0

Anyone see why this doesn't work 

grab-cookie: func [  login-url [url!] username password
    /target web-app-url [url!]
    /local page auth cookie err
][
    if error? set/any 'err try [
        page: open login-url
        cookie: page/locals/headers/set-cookie
        close page
        auth: rejoin [ "login=" username "&pass=" password ]

        page: read/custom login-url compose/deep [ POST (auth) [ cookie: 
        (cookie)]]
        either target [

            page: read/custom web-app-url compose/deep [ GET "" [ cookie: (cookie)]]
            return page
        ][ return cookie  ]
    ][
        mold disarm err
    ]
]   


I can see it sending the cookie after authentication to get a page 
in a web-app, but I get redirected to the login age

Grab-cookie: does your 'username or 'password values contain any 
special character that would need to be URL-encoded?

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.

request/headers/cookie

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

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.

Updated version of Doc's chat example.. 
- Enter key support for login and posting chats
- Cookie mgmt for user name
- various "tweaks" to the JQuery 

chat2.html:  http://pastebin.com/m66a38d50

That chat.html I made was a quick hack of yours. Need to build proper 
cookie mgmt functions.. deal with sessions etc.

if you want to let users login, then you need to track a session 
cookie

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

Doc, I'm thinking this version fixed my cookie issue with Curecode 
. We'll see. So far it looks great. Merci.

ehh... sessions are not lazily created either... and i couldn't even 
set-header 'set-cookie none session/end because it sends down 2 cookies 
then...

Cookie	{RSPSID=YVCBKGUZKHKSJGXVCBSTYDIK; RSPSID=YARKPZJMKJUNWDZRFOLUKJTE}
login	"test"
pass	"letmein"
Session ID	"YARKPZJMKJUNWDZRFOLUKJTE"

yes, it's not sending the cookie as i would expect on the 2nd run

$ 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

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

u know if rebol would come w a nicer header dump, cookie, https and 
url encode/decode support by default, i would advocate it as a curl 
replacement probably... :/

maybe an extension script would be enough, which anyone can remember, 
like http://json.org/json.r

hmm.. cookies are accumlating again... Cookie: RSPSID=GWKAQXFYMANHFHNXLXXKVVWL; 
RSPSID=VDWMLITKUVGDAFQBHJHHCQDH

but the app still works. am i confusing it somehow, by restarting 
cheyenne... but im closing the tab and reopening it too...

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

yeah, using cookies for storage isn't a good idea... also since many 
people are using cookie controlers now.

It might be a good idea to patch in Cyphre's cookie handling support 
as well http://www.rebol.org/view-script.r?script=my-http.r

Hi Doc, one small thing... Chrome browser does not remember the login 
password cookie.

OK, this morning, I went into FF's Cookie browser and searched for 
cookies from my domain where curecode is. There were none.  I went 
to view my curecode page and it was not going to work. I know this 
because the project select shows "none." I then went back to the 
cookies section and there was one for the domain. I deleted that, 
refreshed the curecode page and it worked. 

Now, one thing about my usual usage of curecode and that is during 
any given day, I will end up logging in several times after my sessions 
expire.

0.9.11 beta. Sometimes I am redirected to the login screen but the 
selection  is none and from there it will go to the rsp error. Thanks. 
Knowing that I can remove that cookie is pretty easy.

Doc, I still have issues with the cookies created from Curecode. 
Essentially, when I leave the browser open and the session expires, 
the next time I try to use curecode, it loads up the error page. 
I just manually delete the cookie and I'm good and I have extended 
the timeout as well which helps. I was wondering in the httpd.cfg 
file if there is any value for curecode's timeout that will make 
it endless (perhaps "none" ? ). Thanks. It is a very usefule app.

I use FF 5.0 (just upgraded this morning though. Previously it was 
4.0.1). As far as cookie altering tools, not that I know of, though 
I was wondering if AVG could be doing something. Anyway, I just cost 
you a few lost Red minutes. I'll wait until it happens again.
Thanks.

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?

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>
}
]