You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've spotted shortfalls in the docs for <cfftp> in all of the Adobe docs, Lucee docs and cfdocs:
Only the CF docs mention the structure of the result variable, but even then not explicitly, only in passing in the description of the stopOnError parameter. No mention at all on Lucee's or cfdocs's page.
The CF docs do not mention the result parameter which sets the string name for the variable to put the afore-mentioned result (this overrides the default of cfftp).
NB: on both CF and Lucee (probably cos Lucee is mirroring CF, so not an error on its part), the errorCode and errorText keys are misnamed. They should simply be replyCode / replyText (FTP nomenclature here seems to be "reply", from https://datatracker.ietf.org/doc/html/rfc959, section 4.2) as not all codes reflect an error. EG: a successful connection replies with a code of 230, with text of "login successful" This is analogous to HTTP status codes: only certain ranges reflect error situations.
The text was updated successfully, but these errors were encountered:
via @adamcameron on slack:
I've spotted shortfalls in the docs for
<cfftp>
in all of the Adobe docs, Lucee docs and cfdocs:Only the CF docs mention the structure of the result variable, but even then not explicitly, only in passing in the description of the stopOnError parameter. No mention at all on Lucee's or cfdocs's page.
The CF docs do not mention the result parameter which sets the string name for the variable to put the afore-mentioned result (this overrides the default of cfftp).
Refs:
https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-tags/tags-f/cfftp-opening-and-closing-ftp-server-connections.html
https://docs.lucee.org/reference/tags/ftp.html
https://cfdocs.org/cfftp
NB: on both CF and Lucee (probably cos Lucee is mirroring CF, so not an error on its part), the errorCode and errorText keys are misnamed. They should simply be replyCode / replyText (FTP nomenclature here seems to be "reply", from https://datatracker.ietf.org/doc/html/rfc959, section 4.2) as not all codes reflect an error. EG: a successful connection replies with a code of 230, with text of "login successful" This is analogous to HTTP status codes: only certain ranges reflect error situations.
The text was updated successfully, but these errors were encountered: