World: r3wp
[!Cheyenne] Discussions about the Cheyenne Web Server
older newer | first last |
sqlab 15-Sep-2009 [5702x3] | strange, neither in a browser nor im Rebol with trace/net I see that. |
it seems they all rewrite the answer they present to the user.( | |
by the way, what's the status of ssl? | |
Janko 15-Sep-2009 [5705] | What is the best way to make domain.com to www.domain.com redirection in Cheyenne .. (seo guy advised me that).. in apache you use mod_rewrite: RewriteEngine On RewriteCond %{HTTP_HOST} !^www\.site-assitant\.com$ [NC] RewriteRule ^.*$ http://www.site-assitant\.com%{REQUEST_URI} [R=301,L] |
Graham 15-Sep-2009 [5706x3] | are you sure it's not a cached version you're seeing? |
i.e put some traces in the failure block | |
No SSL unless you use stunnel or similar | |
Janko 15-Sep-2009 [5709x2] | sqlab... I used nginx in front of cheyenne to have SSL .. here http://www.cebelca.biz |
it was quite simple , I just joined two examples from their tutorials .. the SSL and the reverse proxy one .. I can give you the config file | |
Dockimbel 15-Sep-2009 [5711x2] | (using the above test RSP script) >> read http://localhost/set-msg.rsp connecting to: localhost ** User Error: Error. Target url: http://localhost/set-msg.rspcould not be retrieved. Server response: HTTP/1.1 404 Person not found ** Near: read http://localhost/set-msg.rsp |
SSL: It can only be supported by using a third-party front-end like stunnel or nginx. | |
Graham 15-Sep-2009 [5713] | Janko, can you post your config etc |
Dockimbel 15-Sep-2009 [5714x3] | Best way to redirect domain.com to www.domain.com: correctly setup the DNS records. Best way to do it in Cheyenne: (untested) domain.com [ root-dir %/... redirect 301 "/*" "http://www.domain.com" ] www.domain.com [ root-dir ... ] |
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+) | |
For my web sites, I always achieve domain aliasing using CNAME DNS records. | |
sqlab 15-Sep-2009 [5717x2] | ok, clear now. In httpd.cfg was the default on-status-code 404 activated. I had just removed the custom error page. |
I will give nginx a try | |
Will 15-Sep-2009 [5719x3] | 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 | |
nginx has nice things like you can pre gzip your static content so it wont have to compress for each request | |
sqlab 16-Sep-2009 [5722] | thanks for the info. But I will also check stunnel. |
Graham 16-Sep-2009 [5723] | No way yet of encapping a webapp with Cheyenne? |
Dockimbel 16-Sep-2009 [5724] | 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). |
Dockimbel 17-Sep-2009 [5725x5] | SVN r17 : big update, lot of code added mostly for the new embedded async Mail Transfer Agent (MTA) FEAT: email async sending sub-system (MTA) added . FEAT: added two new functions for email support in RSP/CGI scripts: 'send-email and 'email-info? FEAT: added email sending demo form %www/email.rsp. FEAT: Cheyenne's main process ID is now exported in /tmp/cheyenne.pid on start and deleted on quit. (All platforms except Windows). FIX: fixed broken global words protection in RSP.r. FIX: HTTP Date headers are now in UTC format. FIX: "Reset Workers" menu wasn't working in service mode. Fixed now. (Thanks Will) FIX: SVNr4 regression bug on system port for UNIX fixed. (Thanks Will) FIX: multipart file uploading code refactored. Fixes many bugs in file uploading. |
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 | |
In addition : - custom charset can also be set (default to ISO-8859-1"). - attached files are supported. | |
SVN r18: DOC: added quick syntax overview for email API in %www/email.rsp | |
Btw, in order to forge emails to be sent, I've tried to rely on REBOL's builtin email support functions (big mistake!). You should know that they *are not* RFC compliant, the biggest issues being : - emails produces by REBOL are using LF as EOL instead of CRLF (RFC 2822). See http://cr.yp.to/docs/smtplf.html - headers are not encoded for non ASCII-7bits characters (RFC 2047) So, I've deeply patched the builtin code at runtime to workaround this, but, I should have better rewrote it all from scratch (that's what I intend to do when I'll have enough free time). | |
BrianH 17-Sep-2009 [5730] | Write up your patches and we can see about getting them integrated into the next version of R2 :) |
Dockimbel 17-Sep-2009 [5731] | I didn't though that Carl would still support R2 by providing new versions...(surprising but) good news. :-) |
Henrik 18-Sep-2009 [5732] | We need it for R3 too, so it would be wonderful if they could be written simultanoeusly. |
Graham 18-Sep-2009 [5733x5] | nice on the mta ... maybe I should get back to work on my mail server |
I'd probably use Amazon for email. | |
stick the email in a SQS queue ... and remove from the queue when the send is successful. | |
so that way the cheyenne mta can keep trying over 4 days to send the mail. | |
If my cheyenne server goes down .. I can resume from another instance. | |
Dockimbel 18-Sep-2009 [5738] | 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. |
Graham 18-Sep-2009 [5739x3] | I had an email that took 2 days to get a report back from gmail that it could not be delivered. |
That was last month too. | |
I was also thinking of how scaleable it could be made ... | |
Dockimbel 18-Sep-2009 [5742] | Were you satisfied by that or would have you prefered that gmail gives you a failure report 5 minutes max after posting your email? |
Graham 18-Sep-2009 [5743] | I'd prefer instant failure report ... |
Maxim 18-Sep-2009 [5744] | yeah cause we'll try another communication channel right away :-) |
Graham 18-Sep-2009 [5745x2] | but that's not detemined by gmail ... the recipient server might be the cause. |
If you use SQS then you could have a farm of Cheyenne servers sending the mail :) | |
Dockimbel 18-Sep-2009 [5747] | Me too, that's why I'm reluctant to implement it in the old fashion way (retrying every 8 or 12 hours seems way too long now). I would support trying without delays alternative MX servers and if all fail, try 1 or 2 minutes after that. That would be by default, but could be extended by user if required. |
Graham 18-Sep-2009 [5748] | of course it could be your own isp that is the issue ... sometimes we have lost interrnational traffic, but local traffic is okay. |
Dockimbel 18-Sep-2009 [5749] | Emails sending and MX querying are all fully async. Emails are streamed from disk, no memory overhead whatever the email size. You could send hundred (maybe even thousands on fastest machines) of email per second using Cheyenne if needed. |
Graham 18-Sep-2009 [5750x2] | so failing every email ... would not be good. |
Guess we need to field test .. and see how it works | |
older newer | first last |