CGI POST Failure to read Stdin
Sannyasin Sivakatirswami
katir at hindu.org
Thu Apr 8 01:13:11 EDT 2004
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:pass@our.intranet.web.site.org/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
katir at hindu.org
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
>> use-revolution at lists.runrev.com
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
More information about the use-livecode
mailing list