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 --
|
|
