MESSAGE
DATE | 2013-06-15 |
FROM | Ruben Safir
|
SUBJECT | Subject: [NYLXS - HANGOUT] (fwd) Re: HTTP POST for file upload
|
From owner-hangout-outgoing-at-mrbrklyn.com Sat Jun 15 20:57:26 2013 Return-Path: X-Original-To: archive-at-mrbrklyn.com Delivered-To: archive-at-mrbrklyn.com Received: by mrbrklyn.com (Postfix) id 1C3AD16114A; Sat, 15 Jun 2013 20:57:26 -0400 (EDT) Delivered-To: hangout-outgoing-at-mrbrklyn.com Received: by mrbrklyn.com (Postfix, from userid 28) id 01E6A16114C; Sat, 15 Jun 2013 20:57:25 -0400 (EDT) Delivered-To: hangout-at-nylxs.com Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by mrbrklyn.com (Postfix) with ESMTP id 4FBFB16114A for ; Sat, 15 Jun 2013 20:57:25 -0400 (EDT) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mailbackend.panix.com (Postfix) with ESMTP id BA61E2868F for ; Sat, 15 Jun 2013 20:57:26 -0400 (EDT) Received: by panix2.panix.com (Postfix, from userid 20529) id A636A33C9A; Sat, 15 Jun 2013 20:57:26 -0400 (EDT) From: Ruben Safir To: hangout-at-nylxs.com Subject: [NYLXS - HANGOUT] (fwd) Re: HTTP POST for file upload User-Agent: tin/2.0.0-20110823 ("Ardenistiel") (UNIX) (NetBSD/5.1.2 (i386)) Message-Id: <20130616005726.A636A33C9A-at-panix2.panix.com> Date: Sat, 15 Jun 2013 20:57:26 -0400 (EDT) Sender: owner-hangout-at-mrbrklyn.com Precedence: bulk Reply-To: hangout-at-mrbrklyn.com
-- forwarded message -- Path: reader1.panix.com!panix!bloom-beacon.mit.edu!micro-heart-of-gold.mit.edu!nntp.club.cc.cmu.edu!198.15.118.135.MISMATCH!us.feeder.erje.net!feeder.erje.net!eu.feeder.erje.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Josef Moellers Newsgroups: comp.os.linux.networking Subject: Re: HTTP POST for file upload Date: Thu, 06 Jun 2013 21:26:55 +0200 Lines: 58 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net UNT14A4a6G6gVm+jrsgq4wudVwtFnVfyim3KMiYvM4IAHkTYsf Cancel-Lock: sha1:oKylhZgr3yzLuhT9gci6U2dhjdA= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 In-Reply-To: X-Enigmail-Version: 1.5.1 Xref: panix comp.os.linux.networking:496449
On 06/05/2013 07:40 PM, Josef Moellers wrote: > Hi, > > I'm trying to extend an application to upload result files to a web > server using HTMP POST. By and large it works but the last couple of > bytes (the last line, to be precise) does not show up in the received > data. Maybe someone more knowing than I has an idea what I'm doing wrong.
I found the solution in RFC 1341 (:
7.2.1 Multipart: The common syntax : Note that the encapsulation boundary must occur at the beginning of a line, i.e., following a CRLF, and that that initial CRLF is considered to be part of the encapsulation boundary rather than part of the preceding part. :
So I changed my code to
> snprintf(boundary, sizeof(boundary), > "WebKitFormBoundaryePkpFF7tjBAqx29L"); > content_length = 0; > content_length += fprintf(tmpfp, "\r\n------%s\r\n", boundary); > content_length += fprintf(tmpfp, "Content-Disposition: form-data; > name=\"archive_name\"\r\n"); > content_length += fprintf(tmpfp, "\r\n"); > content_length += fprintf(tmpfp, "%s", archive_name); > content_length += fprintf(tmpfp, "\r\n------%s\r\n", boundary); > content_length += fprintf(tmpfp, "Content-Disposition: form-data; > name=\"destination_name\"\r\n"); > content_length += fprintf(tmpfp, "\r\n"); > content_length += fprintf(tmpfp, "%s", remote_name); > content_length += fprintf(tmpfp, "\r\n------%s\r\n", boundary); > content_length += fprintf(tmpfp, "Content-Disposition: form-data; > name=\"file_contents\"; filename=\"%s\"\r\n", local_name); > content_length += fprintf(tmpfp, "Content-Type: > application/x-object\r\n"); > content_length += fprintf(tmpfp, "\r\n"); > while ((nread = fread(buffer, 1, sizeof(buffer), src)) > 0) > { > fwrite(buffer, 1, nread, tmpfp); > content_length += nread; > } > content_length += fprintf(tmpfp, "\r\n------%s--\r\n", boundary);
Apparently the Perl CGI code was tolerant and took the "}\n" as the CRLF preceding the last boundary and dropped that!
Another problem, not related to this one, was that I had to explicitly close the write side of the socket in order to reliably receive the response.
Thanks for both who helped (and all who thought about the issue).
Josef
-- end of forwarded message --
|
|