World: r3wp

I got it working for pdf and jpg, but when I use response/set-header 
'Content-type "image/tiff"  .. it downloads something, but locks 
up FF completely!

try it in REBOL console, download and save the tiff file and try 
to open it to verify that your image is ok.

if you wish to try it ...in FF only as IE can't see the animated 
menus


https://www.compkarori.co.nzas guest 1234 .. click on results->imaging 
, click on the Letter link, and then the link to the tif image ( 
A new one I just uploaded ).

This kills FF 2.04

I don't have any problem with FF.

I can see the image in FF, it's a 'Dell ad'.

I'm on FF v 2.0.0.4

Hmm.  Kills my PC.  Perhaps I have a problem with my PC then?

Time to reformat I guess...

just to add on,

it uses the Quicktime plugin to load the image in FF

It doesn't seem that FF can handle TIFF files natively, I don't have 
the QT plugin so FF just propose me to download the file. I can see 
the TIFF file using my favorite imaging app, so no problem with the 
TIFF image.

Graham, if you really want to serve tiff images and maybe at high 
resolution, look here:
http://iipimage.sourceforge.net/demo.shtml

otherwise as Dock said, quicktime handle tiff format but..

tiff is evil.

tiff is a component based architecture, of which there is no standard 
on the minimal required components.  so can't even be sure of the 
direction of the image, if the image creator didn't include that 
info in the image,

plus, loaders don't understand all the tags, which further increases 
the nightmare.

tiff is only really cool, when you are sure, all your softwares can 
load and save tiffs amongst themselves and they all agree on what 
an image IS...

I've have 24 bit pictures saved from a $10k effects software load 
upside down, black & white in "the gimp".

(as an extreme and real example)

Hey...Tiff is 'in'   Sorry. :)  I agree with Maxim's points.  Just 
had to.

but since tiff allows people to create their own components within, 
 a few "standards" for high-end photography exist IIRC.  These usually 
include HDRI imagery and things like lens aperture and other goodies... 
now, before you get all fuzzy and warm inside.... it doesn't mean 
the data is readable by open softwares, just that its there...

and the main issue is that this info will dissapear whenever you 
save out the image... cause tools like photoshop do not keep it, 
AFAIK.

there was even an image viewer plugin for Windows which would inadvertently 
clear the data whenever you would read pics off you camera!! hehe 
talk about incompetency!  yep, the plugin would open the file read-write, 
seek up till the end of the image data and close the file... which 
would then truncate it  :-) hahahaha

but alas, I just realised we are in cheyenne group... DOH!    sorry 
for the pollution.

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

Changelog :


 o Session cookie management refactored. Cookies are now cached in 
 memory. 
	  Fixes all issues related to timezone.
	  

 o HTTPd request pipeline refactored. It's now more reliable, little 
 faster and

   able to handle extreme situations (stressing with FasterFox). Several 
   core parts
	  of Cheyenne have been touched, so watch out for regressions.
	  

 o Added 'forward method to RSP's Response object (now possible thanks 
 to the 
	  new pipeline engine).
	  

 o Internal modules API changed : 'deferred? property removed (not 
 needed 
	  anymore with new pipeline).
	  

 o Added 'on-status-code option in config file (see example in %httpd.cfg).
	  

 o do-sql now catches internal errors, so they can be more easily 
 located in 
	  calling context.

Remember that I've done some deep changes in this version, so test 
it carefully before putting it online.

Regarding TIFF images, I have no control there.  Incoming faxes are 
saved as TIFF images and stored in the file system.  TIFF because 
they are often multipage images.  I am just serving them out again.

There's another anomaly I have with IE.  If you login as guest and 
click on the link immunizations, it tries to download the page instead 
of showing the 404 handler page which does work with FF.

Content-Type: none, in the response. Are your using version 0.9.13 
and the new 'on-status-code option ?

(btw, I'm watching the response header using IEWatch component)

I'll download 9.13 now

crap .. just overwrote my files with yours :(

Ok, 9.13 fixes the problem with the 404

dockimbel are you available for real support in the next few days?

I have a past project which *might* need to be replaced by cheyenne... 
but I will have tons of questions for sure... and without quick response... 
I am a bit wont to put time on this fix... since I am not totally 
sure it will do what I need....

Max: I'll be online in AltME from 9 jun to 13 jun most of the time, 
so, in this range, I should be able to answer your questions in  
12 hours max delay. But I guess other people, like Will, could also 
answer most of your questions. If you have a lot of questions,m aybe 
it would be better to send them on a private channel, or Chat channel.

Would it be difficult to encap all the rsp pages with Cheyenne so 
that Cheyenne grabs the rsp pages from it's virtual filing system?

have no idea about encapping but maybe look in cheyenne.r and also 
in mod-internal.r  not sure..

ok, so I'll try to look at cheyenne within the next few days.  is 
the MOD building documented anywhere?

/Cheyenne/docs/developer-guide.html + look at the many examples ;-)

thanks.  is the MOD system flexible enough to allow the server to 
be something else than a "WEB" server...  more precisely, a web service, 
I already have all the XML and schema validation libs to make it... 
its just that my current server is blocking and when I relay commands 
to othe servers, it causes timeouts on new commands.

oops on new *connections*

if you don't need the http service than you propably need only uni-engine.r 
and build your own service/protocol otherwise mods can override every 
phase of the httpd .. better wait for DocK..

ok the "every phase of httpd" is just wanted to hear  :-)

web services usually use http, but don't serve out cgi nor web "pages"... 
so the return values are always processed.

has anyone succcessfully used OpenSSL, or is it still a "just use 
OpenSSL" suggestion...

look at phase return codes in the doc, and search in this group for 
phase order execution

If by sucessful you mean Open

SSL... working along side of Cheyenne.. then yeah.. and sTunnel as 
well.

If you mean tying the OpenSSL libs directly via view/pro, then no.

Graham: there's some experimental stuff about that in mod-internal, 
but still needs some improvement to be ready to encap a complete 
web site in the Cheyenne binary. But that's a planned feature, I'll 
provide better support for that in a week or 2.