r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!Cheyenne] Discussions about the Cheyenne Web Server

Graham
5-Mar-2009
[4129x2]
I need cmd for the odbc
If there's nothing I can do to debug this, I'll restart cheyenne
Dockimbel
5-Mar-2009
[4131x4]
You can restart it, I've a copy of the output.
The garbage data seems to increase by 830 bytes each time.
I thought it might be an internal response/buffer corruption (not 
been clear after the request), but the compressed size of the page 
is only 442 (in deflate format).
You should carefully examine each use of response/buffer in your 
RSP code. See if you're not inserting in response/buffer a growing 
 series?
Graham
5-Mar-2009
[4135x3]
server restarted
the only response/buffer I have is ...
nothing
Dockimbel
5-Mar-2009
[4138x2]
You should at least have one occurence for the captcha image
Need to go now, will give it a look tonight.
Graham
5-Mar-2009
[4140]
no, I do have this too ...
		response/buffer: xfdf

        response/set-header 'Content-type "application/vnd.adobe.xfdf"
Dockimbel
5-Mar-2009
[4141x2]
ah :-)
A suspect :)
Graham
5-Mar-2009
[4143]
Ok, let me look at the captcha
Dockimbel
5-Mar-2009
[4144]
Inpect first xfdf
Graham
5-Mar-2009
[4145]
xfdf: {<?xml version="1.0"?>
<xfdf xmlns="http://ns.adobe.com/xfdf/"xml:space="preserve">
<fields>
<field name="Submit"><value>Send</value></field>
<field name="TextField1"><value>$fname</value></field>
<field name="TextField2"><value>$surname</value></field>
<field name="syupdfid"><value>$syupdfid</value></field>
</fields>
<f href="$myhost/testpdf4.pdf?$time"/>
</xfdf>
}
Dockimbel
5-Mar-2009
[4146x2]
Look like we found the culprit :-)
I guess you're appending data to xfdf ?
Graham
5-Mar-2009
[4148x2]
xfdf: copy { }
I should fix that.
Dockimbel
5-Mar-2009
[4150]
:-)
Graham
5-Mar-2009
[4151]
rsp and not cgi
Dockimbel
5-Mar-2009
[4152]
Right
Graham
5-Mar-2009
[4153x4]
:(
thanks ...
If anyone is wonderng what I am doing, I am prefilling in PDF forms 
and sending them to the client browser
the client then fills in the form, and then clicks on the submit 
buttont to send the data back to me.
Dockimbel
5-Mar-2009
[4157]
I think that I should add a "RSP best practice" or "RSP warnings" 
section to Cheyenne's wiki.
Graham
5-Mar-2009
[4158]
yes, that would be helpful :)
Robert
5-Mar-2009
[4159x2]
Graham, the PDF stuff sounds interesting. Any more information about 
this?
Is your PDF sepcified via an XML specification?
Graham
5-Mar-2009
[4161x7]
Robert, xfdf is a deprecated format once used by Adobe to specify 
the contents of fields in a PDF.  So, the above xfdf file will populate 
the fields TextField1, TextField2, syupdfid with $fname, $surname, 
and $syupdfid ... ( well,  I will replace those before I send the 
pdf. )
I will also expand the href to "http://www.compkarori.co.nz:8000/pdfs/testpdf4.pdf? 
+ now (  I do this stop caching the form contents )
So, I send this tiny xfdf file to the browser.  the browser loads 
up the acrobat plugin.  Acrobat now reads the pdf on my website as 
specified in the href field, and then fills in the fields in that 
pdf with the values as specified in the xfdf file.
I have a submit button on the pdf which then sends the data back 
to me.
You can test this by logging to http://www.compkarori.co.nz:8000, 
and then using the "locate" button, ( leave the form blank ) and 
then select any dummy patient.  Then on the bottom left menu, click 
on "test pdf" and then submit.
Note that xfdf does not work with Acrobat PDFs created by Adobe LiveCycle 
.. they want you to move up to their much more expensive forms technology.
Any known issues running Cheyenne on Windows XP 64 or Vista 64 ?
Dockimbel
5-Mar-2009
[4168]
Never tried and I didn't received any feedback from users on that 
platforms.
Graham
5-Mar-2009
[4169x2]
Ok, I'll investigate further with the user ...
Unfortunately I don't have access to either of these to test :(
Dockimbel
5-Mar-2009
[4171]
Maybe someone here using one of these 64bits OS would be kind enough 
to run a few tests for you?
Graham
5-Mar-2009
[4172x4]
That would be good ....Just want to make sure it works.
well, as a temporary measure, if my application can't connect-to 
Cheyenne, it will drop back to the REBOL micro web server which does 
work.  Maybe the user has changed the default port, or has a firewall 
blocking it ... will have to find out.
Ok, seems that the user moved his Cheyenne binary without taking 
my httpd.cfg which I provided.  And so the listen port changed to 
80 which is the default that Cheyenne creates.
I wonder if the default port should be something else as on Vista 
and Linux, that port is not allowed by default.
Dockimbel
6-Mar-2009
[4176x3]
Everybody expects from a web server to run by default on port 80, 
that's the specification. From RFC2616 : "HTTP communication usually 
takes place over TCP/IP connections. The default port is TCP 80 but 
other ports can be used.".
Regarding httpd.cfg file, I'll look on how to avoid writing it down 
on disk when running from a custom encapped binary.
An improvement for Cheyenne on Vista could be to display a standard 
OS security requester asking for admin pass when Cheyenne  needs 
to run on port < 1024.