AltME groups: search

Do you have a short example script showing the issue?

This is the relevant part in a failure block 
<%
..     [
	response/reset
	response/set-header 'Content-Type "text/html"
	response/set-status/msg  404 "Person not found"
	response/end
 ]
%>

strange, 
neither in a browser nor im Rebol  with trace/net I see that.

are you sure it's not a cached version you're seeing?

SSL: It can only be supported by using a third-party front-end like 
stunnel or nginx.

An alternative way could be to defined a default /index.rsp script 
with <% response/redirect/last http://www.domain.com%> (use /last 
refinement only with v0.9.20+)

I will give nginx a try

nginx+cheyenne is a great combination! 8)

how I use it: nginx get all the requests, if a file is not found 
it will proxy-reverse the request to cheyenne wich is configured 
with a on-status-code [404 trap.r] . trap.r check the url request 
and either load and respond with an rsp or send a 404

No way yet of encapping a webapp with Cheyenne?

That requires a virtual filesystem and deep patching Cheyenne to 
use it. I've tried to make one a few months ago, but hadn't enough 
time to finish it. It's a feature I need too (but low pri currently).

A few words about the new MTA and email capabilities :


- Emails are written to disk before sending in async mode. Upper 
email size limit is 2GB. Concurrent emails sending supported (limited 
only by machine resources).

- Only the higher priority MX is used (fallback on others MX should 
be added soon).

- The MTA currently supports only 8BITMIME compliant SMTP servers 
(fallback to 7bit mode will be added if it still make sense to support 
it).

- MTA will  try to send an email once. If the server is busy, it 
will report a failure. Deferred retries will be added using the scheduler 
module (if MX fallback is not enough).

- Emails queue saving should be added in next update (the queue will 
survive to server restart, but not server crash).

- Automatic failure reports are sent back to emitter (From: field).
- Reports can be fully customized.

- Still needs a lot of testing for tracking small errors or issues 
that can trigger antispam filters (e.g. gmail is very picky about 
correct emails format).


You can test it using the provided test script : http://localhost/email.rsp

stick the email in a SQS queue ... and remove from the queue when 
the send is successful.

Cheyenne can be configured to work that way too, but is it desirable? 
I remember the way email was handled 15 years ago, when having failure 
reports after one or 2 days wasn't bothering anyone, but today, we're 
in a world of fast communication (often realtime). When I send a 
mail from gmail, if there's an issue, I get a report in less than 
a minute or two.

I had an email that took 2 days to get a report back from gmail that 
it could not be delivered.

Were you satisfied by that or would have you prefered that gmail 
gives you a failure report 5 minutes max after posting your email?

If you use SQS then you could have a farm of Cheyenne servers sending 
the mail :)

Anyone got a list of 1,000,000 valid email addresses for sale??

Unless your smtp server is a trusted or whitelisted server

Yes, some SMTP servers apply such restrictive rules, but not the 
big ones (AFAICT). But the more important is to have a reverse dns 
that matches your servers domain.

Cheyenne's MTA waits for 5mn before raising a timeout as per RFC.

It's not a timeout, it's a temp failure.

I was quite surprised to see that Gmail and others accepted emails 
sent directly from a MTA on home computer...(I thought that I would 
need to make all testing from remote servers).

You really are creating one of the flagship applications with cheyenne. 
 Something that should be broadcast a bit more outside of the REBOL 
fanbase IMHO.

Many servers do use greylisting, many spammer bots do retry after 
a delay

Max: I want the web control panel and the one-click webapp deployement 
feature for Cheyenne to make it more attractive to non-rebol users. 
Still a lot of work to make it close to what I have in mind.

I should create a fresh checkout

Can you copy/paste the 'win-get-dns function to a fresh console to 
see what happens?

It's a pity that the registry natives are not available in non-encap 
REBOL kernels (not even in /Command)...

using localhost I sent an email to gmail.  I turned on wireshark 
and captured all traffic for a couple of minutes.  no smtp traffic.

a second most of the time

less than a second in fact with gmail, it takes 1-3 sec here to send 
it and get it signaled by Thunderbird.

Is there a log for the email ?

There's a "Email sent" log from MTA in verbose mode (-vv at least)

While testing now, I've noticed a few issue with send-email/attach: 
header and multipart/form-data encoding. I'll fix them tonight, need 
to go now.

I was just doing a straight text test .. but no go.  Even in administrator 
mode.

Can I use virtual hosts to serve multiple document roots on the same 
site without having separate domain names? I I would like to avoid 
"creeping" between multiple sites that don't share code and also 
use it as a tool to avoid the browser accessing code directories 
for the site.

I think I found a different way to do this with symlinks. Thanks.

I think webapps require a bit more than static pages?

It seems that webapps don't require more than an index.html file 
to work, but I get a 404 back or a redirect to the previously shown 
page, when I put an empty index.html file in that dir. When the file 
has just one char, it's served properly.

Like so:

1. create dir test/ in the doc root folder.
2. create empty file index.html in test/
3. try to display in browser: no go
4. insert char "a" in index.html
5. "a" is displayed in browser.
6. remove "a" again so index.html is empty
7."a" is still displayed in browser.


If I navigate away and then back to that page using the Back button, 
it still faithfully displays the "a".


If I directly enter the url for the index.html file, I get bounced 
back to the previous URL.

I guess what I really want is the feature of virtual-root for a webapp, 
but just for plain RSP pages.

Another potential issue is when a virtual-root has the same name 
as a real directory at the default root dir. I don't know if that 
can be warned for, but it caused some confusion here before I figured 
out what was wrong.

cure code is a web app is it not?

yes, it's a webapp.

Sorry, if I'm rambling a little bit. It's what I'm observing that 
is straight reposted here. Moving a few milimeters forward after 
a whole day's work is a bit frustrating, particularly when it's REBOL. 
:-)


Right now I just see that app-init.r is not run and that the loading 
of it is wrapped in an ATTEMPT in Cheyenne's source, so I basically 
can't see what's going on. From the docs it appears that the app-init.r 
file is required for a web-app, but request/web-app returns a web-app 
name. So am I running a real web-app or what's going on?

cheyenne straight out of svn comes with a web app .. does that work?

after a lot of experimentation, the latest encapped version was the 
only one that worked properly.

I wasn't particularly favoring the binary version, only that after 
a day's experimentation, that was the only one that worked properly 
for me. When in such a situation, it's better to stick to one with 
known bug record, so I can tell whether it's the binary or me that's 
doing something wrong.

so, the main advantage is the practicality  (it also easier to update 
a single binary than a whole repository on the server itself :-)

Two other issues in the 0.9.19 source:


1. INCLUDE and INCLUDE-FILE do not process paths identically. This 
is not mentioned in the docs.

2. INCLUDE won't include files in absolute paths. It simply changes 
the path to the current path which stores the RSP file that is currently 
being executed. I can't say that I have a fixed include directory 
somewhere at an absolute path. I don't see the purpose of altering 
the path like this.

Sometimes Cheyenne also outputs a lot of junk prior to the real content. 
This seems to coincide with a failed INCLUDE. Rebooting Cheyenne 
stops the problem.

Graham, I'm running Cheyenne on a remote headless Linux server, so 
no system tray. :-)

not happening. besides, I prefer knowing what Cheyenne actually does 
than beating on a black box with a club to make the black box work. 
:-)

My app reports errors back to me ... 

I do a set-net [ [myemail-:-gmail-:-com] gmail-smtp-in.l.google.com ]

and then send the message to me.

I don't need to use SSL/TLS because the recpient is also a gmail 
account.

DocKimble, I've rambled a lot the past couple of days. I still have 
more to come. Can you make sense of it or should I compile a document 
with suggestions?

Henrik, trying to answer your questions/issues :


to serve multiple document roots on the same site without having 
separate domain names

 => Use sub-domains for such isolation. Everything that's under one 
 domain can be accessed with /.. parent syntax. I think that you can 
 hack it around with ALIAS, custom webapps on-page-start event  handler, 
 but there aren't clean solutions. Use sub-domains for such isolation.

I think webapps require a bit more than static pages?

 => Just to make it clear, webapps are REBOL applications interfaced 
 with external world using RSP scripts. Webapp are not meant to be 
 container for *only* static pages (HTML/CSS/JS/images).


attempt [load join request/config/root-dir %/app-init.r] ; TBD: report 
errors !!! [...] 
RSP: error in events from %app-init.r now logged. 
That's from the change log. That's not correct.

 => Yes it is. What's being logged so far is the errors caught at 
 runtime in event functions declared in app-init. What need to be 
 logged is the LOAD %app-init.r process (syntax errors at boot time).


after a lot of experimentation, the latest encapped version was the 
only one that worked properly.

 Both encap and sources versions works well on Win/Mac/Unix. The issues 
 you have are related to running a rebol app as daemon in console 
 mode on a remote Unix server (without a UI desktop). Cheyenne can 
 work in source mode on such server, but it's much easier and pratical 
 to use it in binary form in such case (typical remote linux server 
 case).

so, now app-init.r works for whatever reason. at least I can observe 
that changes to app-init.r only take into effect after restarting 
Cheyenne.

 => Webapp are persistent application in memory. RSP pages will be 
 reloaded on modification but %app-init.r can't without "restarting" 
 the whole application. As there's no clean/reliable way to completly 
 "unload" a Rebol app from a Rebol session, it requires to restart 
 the whole processes (all the worker background processes that may 
 have run your webapp). This can be achieved either by restarting 
 the whole server, or better, by using the "Restart Workers" feature 
 (documented in the changelog file). For unix: kill -USR1 <pid> (where 
 <pid> is Cheyenne main process id).

Use the provided TestApp webapp sample to get a real working example. 
You can build your app by copying testapp code, then customizing 
it if you don't feel yet comfortable with webapps framework.

Graham: I'll release a new SVN version in a few hours after fixing 
known bugs/issues and rewritten netutils and file attachement stuff 
to get rid of Rebol non-conforming legacy code.

I need it to be fully operationnal for tomorrow, we're starting UAT 
for a customer app relying on it. ;-)

Correcting myself about my claim regarding CRLF not sent by REBOL 
built-in protocols : REBOL does send CRLF even if 'newline if used 
as line terminator. A conversion is applied and it becomes CRLF once 
inserted in the port. This automatic conversion (LF=>CRLF) is OS 
independent and is triggered by /lines refinement used on OPEN native 
in root-protocol/open-proto. AFAICT, this behaviour is not documented 
explicitely anywhere. I can just find a few mentions about such conversion 
here : http://www.rebol.com/docs/core23/rebolcore-12.html, but it 
looks like it's related to FTP scheme only (while in fact being the 
default for all schemes relying on OPEN-PROTO).

I wonder if the /lines is a recent refinement or if I just never 
noticed it.

darn, a single little thing goes unnoticed and this ends up causing 
so much grief!!  :-)

oh .. so you need to select a file first to see the field?

Could you send me privately a log session from Cheyenne recorded 
with -vvvvv?

a 421 code + a MX retrieving failure

that query is traversing a lot of layers...some of them might implement 
some sort of retries if first request doesn't work.

I'd like to test first a more robust MTA. Going to sleep now. Thanks 
for the time you took for testing.

Is there a way that I can use a a href to invoke a program on the 
local drive or does the security prevent this?

no matter ... I found a way to do this via content-type  ...


just need to translate this php to rsp http://www.dklevine.com/general/software/tc1000/jarnsample3.php

just wondering if url-encode should also take file! as a parameter

doesn't sound like a common case? Using FORM should be enough : 
<%= url-encode form %file %>

Btw, I didn't understood what you wanted to achieve by "use a a href 
to invoke a program on the local drive"? You mean running an executable 
on the server with a hypertext link? (I guess you're targeting a 
server on localhost?)

yes I am using form already .. but forme it's a common scenario to 
display files from the web server's directories

SVN r23 :


FEAT: improved logging and error handling for dig/SMTP/MTA modules.

FEAT: integration of deferred retries in MTA for temp errors recovering 
and greylisting passing.

FEAT: new config keyword in global section: dns-server. (see changelog.txt)

FIX: in email generation, added a missing CRLF between headers and 
body.
FIX: logger sub-second times output padding fixed.
FIX: minor code cleanups.

In dig.r line 174 should read

			pick dns-server switch strategy [
as there is a typo there.

SVN r25

FEAT: encap paths are now in a separate file (%encap-paths.r)

Thanks Graham - what should I do with the first run of Tortoise? 
I suppose I better don't do Check-out? Should I create a "working 
copy"? I don't remember how I did it for Rebgui, as I am long time 
issuing Update item from the context menu. I need to do first sync 
of Cheyenne now, and would not like to screw something on the server 
side :-)

you want to do a SVN update

well, it's not working yet ffor me ... when meeting a greylisting 
server

It's for Cheyenne only usage. Sending email is often required in 
web applications, setting up and maintaining a third party MTA like 
sendmail is costly and complicated. Having a MTA built in Cheyenne 
will save everyone a lot of time and troubles.

If any user wants to extend its capabilities to make a complete sendmail/qmail/postfix/... 
replacement, you're welcome.

In the www directory there's a demo file called email.rsp which you 
can use to test the MTA.  Change line 58 to your own from address.

This r27 is the first version that successfully attempts to resend 
a greylisted email ... so far it has retried twice to send my mail 
to google, but google keeps temp failing my mail :(  Guess my IP 
address is marked as a spam source.

Moved to a different IP adddress to test ..gmail still temp fails 
me!

Does it return a 421?

So, this could be an issue for a server with no mx record

I should add a From: field in %email.rsp. I'll set the retry delay 
to 5 mn also.

Btw, if you're a Cheyenne user, that would be nice is you could tell 
it to ohloh.net here : http://www.ohloh.net/p/cheyenne-server

Ohloh seems to become trendy, not sure if it's a good thing or not, 
anyway Cheyenne is listed there so...

There are a couple of projects by Volker referenced there .. but 
I didn't see any source code.

Ohloh is crawling in Google Code's and probably Sourceforge's repositories. 
Volker has a few projects in Sourceforge.

I'm need to get the name I assigned a face when I alt-click on it. 
I can get its style, offset, size etc but I do not see a way to get 
the face's name. More specificly I have multiple scroll-panels and 
I need to know the one I'm clicking in...

because I use duplicate cgi names .. ie. from and file, they are 
turned into a block when processed

Nice idea! A REST-like interface to Cheyenne's MTA using the demo 
email form. :-)

I like the fact that I can pass a file! so that I don't have to figure 
out how to do a multipart upload to the mail.rsp script.

Also in chrome when you select a file, it just shows the filename 
... I wonder if and where it is storing the full path.

SVN r30 :


FEAT: MTA engine refactored, jobs are split in sub-tasks allowing 
more reliable and cleaner code.
FEAT: Default SMTP delay reduced to 5mn.

FEAT: MTA queue can now be saved on disk when server is restarted 
(persist [mail-queue])

FEAT: added native DNS async wrapper for UniServe (protocols/DNS.r)

FEAT: replaced blocking DNS calls for MX domain resolution by async 
DNS calls.

FEAT: 'on-mx event in DIG protocol now returns a block of all the 
declared MX.

FEAT: now all MX will be tried in right order by the MTA if connexion 
fails.
FEAT: improved SMTP logs by prefixing with a SMTP session ID.

FEAT: upload data in HTTPd limited to 2GB (max supported by integer! 
type)

FEAT: 'email-info? RSP function return data format improved (see 
email.rsp header)

FIX: email.rsp minor bugs fixed and From: field added.
FIX: minor fixes in email.r library.

FIX: now uni-engine's logging level is also set by 'set-verbose function.