Comproba a resposta final de FTP antes de confiar nunha subida

Un cliente FTP pode aceptar unha orde put moito antes de que o servidor recibise o ficheiro, e a fenda entre eses dous acontecementos é onde viven case todos os misterios da subida. Hai que completar catro etapas: lese o ficheiro local, o servidor acepta a solicitude de almacenamento, a conexión de datos transporta os bytes e a transferencia chega a unha resposta final positiva. Comparar as etapas é máis útil que comparar clientes, porque un inicio de sesión que funciona e un nome de ficheiro que aparece quedan ambos antes do final.

Resposta preliminar fronte a resposta final

Para STOR, unha resposta 125 ou 150 é preliminar. Di que o servidor está disposto a intentalo e que se abre unha conexión de datos, non que o obxecto exista na súa forma final. A operación só se completa cando a transferencia chega a unha resposta positiva de finalización, normalmente 226 ou 250, no contexto desa operación.

Unha 426 significa que a transferencia se abortou, e un número impreso por outra orde non é o resultado desta subida. Le a resposta que pertence ao STOR, non o último número da pantalla. Se o cliente sae antes de que chegue esa resposta, non tes ningunha proba de finalización.

Conexión de control fronte a conexión de datos

A autenticación e o listado de directorios usan a conexión de control. Os bytes usan unha conexión de datos aparte, e o seu extremo négociase para cada transferencia. Un inicio de sesión correcto demostra a ruta de control e non di nada sobre se o enderezo de datos é alcanzable desde o cliente.

Cando o servidor non pode abrir a conexión de datos, investiga o extremo negociado e a ruta permitida. O modo pasivo segue esixindo un enderezo de datos e un port utilizables, e un cortafogos ou un dispositivo NAT entre cliente e servidor pode permitir a sesión de control mentres bloquea o rango de datos. Cando o servidor rexeita a solicitude de almacenamento, mira o nome de ruta remoto, os permisos ou os límites de almacenamento. Ningunha das dúas ramas se explica porque a conexión de control se autenticase.

FTP sobre TLS fronte a SFTP

FTP sobre TLS segue sendo FTP: dúas conexións, respostas FTP e unha actualización a TLS en cada unha. SFTP é un subsistema de SSH cunha soa conexión e un conxunto de ordes completamente distinto. Comparten un propósito e case nada máis, así que un diagnóstico que salta entre eles adoita comezar comparando os rexistros equivocados.

Non desactives TLS para que un axudante intermedio poida inspeccionar a sesión, e non trates un fallo de SFTP como un problema de respostas FTP. O manual de curl documenta TLS explícito, modo pasivo e opcións de subida se necesitas unha proba con script, e é a referencia do que cambia realmente cada opción.

Escolle o protocolo que o servizo ofrece de verdade antes de depuralo. Un servidor que só fala SFTP nunca producirá unha resposta 226, por moito que se configure o cliente.

Un nome de ficheiro visible fronte a un obxecto almacenado

Un nome de ficheiro visible pode representar un obxecto incompleto, sobre todo tras unha transferencia abortada ou un cliente que saíu antes de tempo. Pide ao propietario do servizo que compare o tamaño do ficheiro de proba previsto e o hash de contido de confianza co obxecto almacenado cando se espera preservar os bytes.

Os modos binario e ASCII son outra comparación que cambia o resultado. O modo ASCII pode traducir os finais de liña, así que os bytes almacenados difiren do ficheiro local aínda que a transferencia tivese éxito. Mantén o modo binario para unha comprobación byte a byte, e non engadas opcións de conversión para que unha transferencia fallida pareza distinta.

Un STOR normal pode substituír un ficheiro existente, e o permiso para iniciar sesión ou listar un directorio non establece o permiso para crear ou substituír un obxecto nel. Usa para a proba un nome remoto non utilizado antes.

Que comparar antes de reintentar

Non engadas, non retomes nin repitas unha subida a cegas sobre un ficheiro parcial incerto. Acorda co propietario se cómpre reiniciar cun nome novo, usar o procedemento de recuperación admitido polo servizo ou eliminar o obxecto de proba fallido.

Escribe o resultado como unha de catro afirmacións: a lectura local fallou, rexeitouse o almacenamento, a transferencia de datos abortouse, ou a transferencia completouse e os bytes almacenados coincidiron. Ese rexistro é un resultado máis sólido que cambiar o intérprete, a VPN e os axustes de FTP á vez ata que apareza un nome de ficheiro, e di á seguinte persoa que etapa inspeccionar. Garda o texto de resposta saneado xunto con esa afirmación. Entón un reintento é unha decisión, non un reflexo.