I changed the title of this thread to more accurately reflect the real issue as we think we have discovered it to be:

Failure of the Rev CGI Engine to properly accept data from a POST by a Rev Client except with very
specific syntax....


This is probably something we need to carve into stone to save future CGI users a lot of grief.
And, its quite bizarre and unintuitive. And we still don't know the deep causes behind it, only a solution.


further examination of the apache error logs showed

192.168.1.246 - sevak [07/Apr/2004:17:53:08 -1000] "POST /cgi-bin/uploadGitaTranscript.cgi HTTP/1.1" 200 -

There should be a length value at the end of that string e.g. 200 - 1158

The absence of the length value indicates that, apparently, apache is not getting any POST data at all into stdIn from the Rev client app... but our sys admin here was thinking that his Apache and OSX server were solid and he ask me to try to post the same url encoded string from the terminal using

curl -k "http://user:[EMAIL PROTECTED]/cgi-bin/niftyRev.cgi" -d "long urlEncoded string of name=value pairs here"

Ok, so in this case the POST is coming from the terminal --> LAN --> OSX server --> apache --> Revolution darwin engine:

it worked every time!

so, this would at first have indicated there was a problem with the Revolution client app sending the POST string. But the same client app works fine, posting to the same Rev cgi on a solaris machine where the engine is an old Metacard engine

Then we dug out an old note from Scott Raney on this subject of POST failures where there was a lot of data being sent... but we had been experiencing this even on very small data uploads... and the syntax in the CGI he sent for the fix reads:

put empty into tIncomingData
repeat until length(tIncomingData) >= $CONTENT_LENGTH
   read from stdin until empty
   put it after tIncomingData
end repeat

Jai Ganesha! That works... so, it is some very esoteric, obscure issue about the way POST is being generated by the Rev client that requires this specific mode of reading stnIn in order to work, even though if you just used

read from stnin untiil empty
put it into tIncomingData

it *will* work just fine if the POST string is sent by some other remote agent besides a remote Revolution app...

but the following does *not* work.

repeat while length(tIncomingData) <= $CONTENT_LENGTH
   read from stdin for $CONTENT_LENGTH
   put it after tIncomingData
end repeat

Don't ask "why" ;-)


Jeanne... can you add this to the documentation for CGI side scripting? And, if Scott Raney is still in the loop we would love his input on this.

Sannyasin Sivakatirswami
Himalayan Academy Publications
at Kauai's Hindu Monastery
[EMAIL PROTECTED]

www.HimalayanAcademy.com,
www.HinduismToday.com
www.Gurudeva.org
www.Hindu.org

On Apr 7, 2004, at 12:37 PM, Sannyasin Sivakatirswami wrote:

Good intuitive sleuthing, David!

OK I added the expected variable to tResponse being sent back and that's very helpful.. what is happening, in either mode of reading stndIn... is that the variable that should contain the incoming data is completely empty! but, *occasionally* it does work.

Bottom line now seems to be: POST is failing completely on most occasions, either in the client side Rev App which is posting an empty string... or on the Darwin side server CGI interpreter which is failing to read anything at all from stnIn from the client side Rev App. a) it NEVER works if I use the "repeat while len() form b) it works But it does work *sometimes* Arghh! ;-)

Whether I do either of these:

repeat while length(tIncomingData) >= $CONTENT_LENGTH
   read from stdin for $CONTENT_LENGTH
   put it after tIncomingData
end repeat

put tIncomingData into tCheckRawData
put  urlDecode (tIncomingData)  into tDataIn

--[or:]

--read from stdin until empty
--put it into tCheckRawData
 -- put  urlDecode (it)  into tDataIn

I get the same result

can't open file

/remote-team/ ## this shows that both the tUser and tFilename are empty


I also added a data check to put the entire string of urlEncoded data into a variable to test at the end and return in the response like this:


put the Result & cr & cr & tFilePath & cr & cr & tCheckRawData & cr & cr into tResponse

If I use the "repeat while len..." etc style, tCheckRawData contains the literal variable "tIncomindData" which I assume means that tIncomindData is, as a container, empty.

if I use the simple 'read from stnin until empty; put it into tCheckRawdata"

the response line that should contains that data is completely empty.

Conclusion at this point:

POST is failing completely on most occasions, either in the client side Rev App which is posting an empty string... or on the Darwin side server CGI interpreter which is failing to read anything at all from stnIn from the client side Rev App. Arghh! ;-)

Ok, what now? I'll move this whole scenario over to our virtual host site at mahiai.aloha.net where we have an old version of MC running on a solaris... then if it works there we kind of have it isolated to the current versions of Rev... OR OSX server version of Apache or Darwin?

Any more suggestions? I REALLY need this to work as our server admin has turned off FTP and now this is the only way I can get data in from the outside.




On Apr 6, 2004, at 9:23 PM, Dave Cragg wrote:


At 6:49 pm -1000 6/4/04, Sannyasin Sivakatirswami wrote:

Simply stated: the CGI accepts incoming data from a POST and writes
it to a file sometimes and sometimes it says it can't open the file.
No pattern...

CONTEXT:

<snip>

the CGI (truncated a bit for email purposes:) goes like this:


on startup

if $REQUEST_METHOD is "POST" then
read from stdin until empty
  put  urlDecode (it)  into tDataIn
    split tDataIn by "&" and "="
    put tDataIn["_remotestaff"] into tUser
    put tDataIn["_project"] into tProject
     put tDataIn["_transcript"] into tTranscript
     put tDataIn["_fileName"] into tfileName
put url "file:transcriptionTeam.txt" into tAuthenticate
if  (tUser is among the lines of tAuthenticate) then
 # set up a file path to the incoming transcription
 # it will just be a small xml file
  switch tProject
 case "taka"
 put "/taka/New-Not Yet Posted/" into tLocalDestination
 break
  case "gita"
 put "/gita/new_incoming/" into tLocalDestination
 break
 end switch
 put ("../remote-team/" & tUser & tLocalDestination & tFileName)
into tFilePath

 # next: open, write data and close the file
## !! but here is the problem:
## this attempt to write a file fails intermittently...
# sometimes apache writes the file
# other times it returns "can't open file" to the result

put tTranscript into url ("file:" & tFilePath) ## fails intermittently

put the Result & cr & cr into tResponse # sometimes empty some times
"can't open file"

## send stuff back to the user to confirm, along with the result

end start up

What is happening is when then the user clicks the button in the
remote rev app, to trigger the upload to Kauai it may return result:
"can't open file" then he clicks again  and this time gets no result
and the file is written.

One thing you might want to check first is that the CGI is reading in all the data.


  repeat while length(tDatain) >= $CONTENT_LENGTH
    read from stdin for $CONTENT_LENGTH
    put it after tDatain
  end repeat

I can't say for sure, but looking quickly at your code, it seems you might get the error you described if the tUser variable was in fact empty and the tAuthenticate variable contained an empty line. You could check this by returning tFilePath when you get an error to see if the file path is the one you expect.

Cheers
Dave
_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution


_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution


_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to