Skip Menu | will be shut down on March 1st, 2021.

This queue is for tickets about the HTTP-Body CPAN distribution.

Report information
The Basics
Id: 109584
Status: open
Priority: 0/
Queue: HTTP-Body

Owner: Nobody in particular
Requestors: zhurs [...]

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)


MIME-Version: 1.0
X-Spam-Status: No, score=-2.699 tagged_above=-99.9 required=10 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
X-Mailer: Yamail [ ] 5.0
X-Spam-Flag: NO
X-Virus-Checked: Checked
Content-Type: multipart/mixed; boundary=""
Message-ID: <928671448381506 [...]>
X-Virus-Scanned: Debian amavisd-new at
X-Spam-Score: -2.699
Received: from localhost (localhost []) by (Postfix) with ESMTP id 65FD6240310 for <cpan-bug+http-body [...]>; Tue, 24 Nov 2015 11:12:06 -0500 (EST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aw-TD-+8xhTM for <cpan-bug+http-body [...]>; Tue, 24 Nov 2015 11:12:04 -0500 (EST)
Received: from ( []) by (Postfix) with SMTP id 9EA73240305 for <bug-http-body [...]>; Tue, 24 Nov 2015 11:12:03 -0500 (EST)
Received: (qmail 25344 invoked by alias); 24 Nov 2015 16:12:03 -0000
Received: from (HELO ( by (qpsmtpd/0.28) with ESMTP; Tue, 24 Nov 2015 08:11:52 -0800
Received: from ( [IPv6:2a02:6b8:0:f05::16]) by (Yandex) with ESMTP id B6D44700999 for <bug-http-body [...]>; Tue, 24 Nov 2015 19:11:47 +0300 (MSK)
Received: from (localhost []) by (Yandex) with ESMTP id 3B68F278270A; Tue, 24 Nov 2015 19:11:47 +0300 (MSK)
Received: by with HTTP; Tue, 24 Nov 2015 19:11:46 +0300
Authentication-Results: (amavisd-new); dkim=pass header.i= [...]
Delivered-To: cpan-bug+http-body [...]
Subject: new feature for HTTP::Body::OctetStream - use memory buffer instead temp file for small bodies
Return-Path: <zhurs [...]>
X-RT-Mail-Extension: http-body
X-Original-To: cpan-bug+http-body [...]
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail; t=1448381507; bh=oJcEpI3/1HoiqU8m1pSEPHNTLSyaPeKJ82C6OEJVqaI=; h=From:To:Subject:Date; b=LEEI9G2Zv4nEdx83UjoApiq1cZUM62W5kKdK4vAOzR7Zn0JE0rqOQ6pTFZ0zJxq/t LyoVCOmoJCJhTumxtn3ctUXAsiHOQ0278h/xg+pyfli/Zd3DblbtNP7Juxu/zBv26M kOAFu0x/wxn4J4C1hqgIK9yLRJZfYDpaIxKyV7qY=
Date: Tue, 24 Nov 2015 19:11:46 +0300
To: bug-http-body [...]
From: Сергей Журавлёв <zhurs [...]>
X-RT-Interface: Email
Content-Length: 0
content-type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-RT-Original-Encoding: ascii
Content-Length: 489
Download (untitled) / with headers
text/plain 489b
Hello, We have json API, built using Plack, so every request have Content-Type: application/json. Plack uses HTTP::Body, that choose HTTP::Body::OctetStream for this type of requests, and create new temporary file for each request. It hurts performance of our service. So, I make patch, which uses PerlIO if body is small and File::Temp for big queries. Also it is possible to tune behaviour through shared variable MAX_BUFFER_SIZE. Please, consider to include patch into distribution.
Content-Type: text/x-diff; name="buffered-octet-stream.patch"
Content-Disposition: attachment; filename="buffered-octet-stream.patch"
Content-Transfer-Encoding: base64
Content-Length: 4069

Message body is not shown because sender requested not to inline it.

MIME-Version: 1.0
In-Reply-To: <928671448381506 [...]>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <928671448381506 [...]>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-17945-1457521060-1464.109584-0-0 [...]>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 1015
Download (untitled) / with headers
text/plain 1015b
On 2015-11-24 16:12:07, wrote: [...] Show quoted text
> and create new temporary file for each request. > It hurts performance of our service. > > So, I make patch, which uses PerlIO if body is small and File::Temp > for big queries.
Hmm - I can see the appeal, but I'm not sure I really like the idea of the behaviour of what you get back differing depending on the size of the request - it sounds like a way to get weird, hard to debug problems. On the other hand, if we use IO::Handle::Utils::io_from_any() as I'm doing in the UrlEncoded handler, and we document that the body() method will return an IO::Handle-like object which can be read from to get the body content, but makes no promises on the specific type of handle, then calling code should be OK with it. I'll give this a little more thought and run it by others, but I certainly approve of being able to stop it writing temp files - both for performance, and to avoid potentially-sensitive request contents being (even temporarily) stored on disk.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to