Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

459
Vistas
Carga de archivo de formulario de varias partes: el archivo cargado a veces tiene un salto de línea adicional al final del archivo

Tengo un problema bastante loco y espero que alguien pueda darme algún consejo sobre cómo solucionarlo.

En el lado del cliente, subo un formulario de varias partes a un servidor usando C #. En el formulario hay un campo para un hash MD5 y un campo para un archivo de audio.

El problema es que a veces sucede que un archivo de audio cargado tiene un salto de línea al final del archivo que no está presente en el archivo original del lado del cliente. Y esto, por supuesto, hace que falle la verificación de hash MD5.

Me sorprende que esto sólo suceda a veces. De 200 solicitudes hay una con el problema descrito.

Aquí está el código de mi clase HttpMultipartFormSender:

 public class HttpMultipartFormSender { private HttpRequestMessage _requestMessage; public HttpMultipartFormSender(string requestUri) { UploadProgressHandler = new ProgressMessageHandler(); var boundary = "----------" + DateTime.Now.Ticks.ToString("x", CultureInfo.InvariantCulture); Content = new MultipartFormDataContent(boundary); _requestMessage = new HttpRequestMessage(HttpMethod.Post, requestUri); } public MultipartFormDataContent Content { get; set; } public ProgressMessageHandler UploadProgressHandler { get; } public async Task<bool> SendFormAsync() { _requestMessage.Content = Content; var client = HttpClientFactory.Create(UploadProgressHandler); client.Timeout = TimeSpan.FromMinutes(30); var httpResponse = await client.SendAsync(_requestMessage); if (!httpResponse.IsSuccessStatusCode) { throw new InvalidOperationException("Exception thrown while file upload"); } return true; } #endregion }

Y el uso se parece a:

 VmPropUserMessage = $"File: {Path.GetFileName(filePath)} is uploading..."; await using var fileStream = new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.Read); var md5StringContent = new StringContent(GetFileMd5(filePath)); var fileStreamContent = new StreamContent(fileStream); fileStreamContent.Headers.Add("Content-Type", "application/octet-stream"); var formSender = new HttpMultipartFormSender($"{VmPropSelectedTranscoder.Url}/upload"); formSender.UploadProgressHandler.HttpSendProgress += FileUploadProgressChanged; formSender.Content.Add(md5StringContent, "file_hash"); formSender.Content.Add(fileStreamContent, "file", filePath); await formSender.SendFormAsync();

En el lado del servidor, uso este código cortado para almacenar la transmisión de la solicitud:

 private static void SaveFile(TranscodingJobModel transcodingJob, Stream requestFileContent) { var uploadedFilePath = $"{AppConfig.AudioUploadDir}\\{transcodingJob.GetTranscodingJobTmpFileName}"; using (var fileSaveStream = File.Create(uploadedFilePath)) { requestFileContent.CopyTo(fileSaveStream); fileSaveStream.Flush(true); fileSaveStream.Close(); requestFileContent.Close(); } }

A veces tengo este resultado:

En el lado del cliente, el archivo termina con una sola línea nueva:

En el lado de la fuente

En el lado del servidor, el archivo termina con dos nuevas líneas:

En el lado de destino

¿Alguien tiene una idea de por qué ocurre esto?

Gracias por adelantado

over 4 years ago · Santiago Trujillo
1 Respuestas
Responde la pregunta

0

La especificación de contenido multiparte tiene algunas expectativas de sintaxis específicas con respecto a CRLF/líneas nuevas:

https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html

Tenga en cuenta que el límite de encapsulación debe ocurrir al principio de una línea, es decir, después de un CRLF, y que ese CRLF inicial se considera parte del límite de encapsulación en lugar de parte de la parte anterior. El límite debe ser seguido inmediatamente por otro CRLF y los campos de encabezado para la siguiente parte, o por dos CRLF, en cuyo caso no hay campos de encabezado para la siguiente parte (y por lo tanto se supone que es de tipo de contenido/texto). simple). NOTA: El CRLF que precede a la línea de encapsulación se considera parte del límite, por lo que es posible tener una parte que no termine con un CRLF (salto de línea). Las partes del cuerpo que deben considerarse que terminan con saltos de línea, por lo tanto, deben tener dos CRLF antes de la línea de encapsulación, la primera de las cuales es parte de la parte del cuerpo anterior y la segunda es parte del límite de encapsulación.

El requisito de que el límite de encapsulación comience con CRLF implica que el cuerpo de una entidad multiparte debe comenzar con CRLF antes de la primera línea de encapsulación, es decir, si no se usa el área de "preámbulo", se deben seguir los encabezados de entidad. por DOS CRLF. De hecho, así es como deberían estar compuestas tales entidades. Sin embargo, un programa de lectura de correo tolerante puede interpretar un cuerpo de tipo multiparte que comienza con una línea de encapsulación NO iniciada por un CRLF como un límite de encapsulación, pero un programa de envío de correo compatible no debe generar tales entidades.

El tipo MultipartFormDataContent hereda el comportamiento de MultipartContent, donde la fuente subyacente ayuda a ilustrar cómo .NET maneja la aplicación de esta especificación al combinar varios elementos de contenido subyacente:

  • https://github.com/dotnet/runtime/blob/release/5.0/src/libraries/System.Net.Http/src/System/Net/Http/MultipartContent.cs

Menciono esto porque parte de la especificación implica que se agreguen nuevas líneas como parte de la segmentación del contenido y puede ser una oportunidad para que usted escriba una prueba unitaria en el cliente con su archivo ofensivo para generar el MultipartFormDataContent y evaluarlo en múltiples etapas. para reducir dónde radica el problema y si ese problema está en el código de generación de contenido del cliente o en el código de consumo del servidor. Si inspecciona el contenido del archivo antes de que el contenido de varias partes se procese en una transmisión, ¿aún coincide? Si procesa el contenido de varias partes en una secuencia y lee esa secuencia localmente (sin enviarla por cable), ¿sigue coincidiendo?

over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda