Skip Menu |
 

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

Report information
The Basics
Id: 90414
Status: resolved
Priority: 0/
Queue: HTTP-Proxy

People
Owner: Nobody in particular
Requestors: vincenzo.buttazzo [...] altervista.it
Cc:
AdminCc:

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



From vincenzo.buttazzo [...] altervista.it Fri Nov 15 11: 58:43 2013
MIME-Version: 1.0
X-Spam-Status: No, score=-6.89 tagged_above=-99.9 required=10 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_FRT_STOCK2=0.01] autolearn=ham
X-Spam-Flag: NO
Message-ID: <op.w6loa5qph9spqn [...] localhost>
content-type: text/plain; charset="utf-8"; delsp="yes"; format="flowed"
X-Received: by 10.14.5.133 with SMTP id 5mr921693eel.84.1384534709998; Fri, 15 Nov 2013 08:58:29 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Organization: AlterVista
X-Spam-Score: -6.89
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id C45DE24060B for <cpan-bug+HTTP-Proxy [...] hipster.bestpractical.com>; Fri, 15 Nov 2013 11:58:43 -0500 (EST)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AApNv2mwjKvB for <cpan-bug+HTTP-Proxy [...] hipster.bestpractical.com>; Fri, 15 Nov 2013 11:58:41 -0500 (EST)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 9A70F2400D5 for <bug-HTTP-Proxy [...] rt.cpan.org>; Fri, 15 Nov 2013 11:58:41 -0500 (EST)
Received: (qmail 21102 invoked by alias); 15 Nov 2013 16:58:40 -0000
Received: from mail-ee0-f47.google.com (HELO mail-ee0-f47.google.com) (74.125.83.47) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Fri, 15 Nov 2013 08:58:34 -0800
Received: by mail-ee0-f47.google.com with SMTP id c50so653305eek.34 for <bug-HTTP-Proxy [...] rt.cpan.org>; Fri, 15 Nov 2013 08:58:30 -0800 (PST)
Received: from localhost ([82.112.213.251]) by mx.google.com with ESMTPSA id 8sm8031483eem.15.2013.11.15.08.58.28 for <bug-HTTP-Proxy [...] rt.cpan.org> (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 15 Nov 2013 08:58:29 -0800 (PST)
Delivered-To: cpan-bug+HTTP-Proxy [...] hipster.bestpractical.com
User-Agent: Opera Mail/12.16 (Linux)
Subject: HTTPS data transfer fails
Return-Path: <vincenzo.buttazzo [...] altervista.it>
X-RT-Mail-Extension: http-proxy
X-Original-To: cpan-bug+HTTP-Proxy [...] hipster.bestpractical.com
X-Spam-Check-BY: la.mx.develooper.com
X-Google-Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:to:date:subject:mime-version :content-transfer-encoding:from:organization:message-id:user-agent; bh=Wb4h1o7ondPavQ4IEHBNnyL8fw0PBT334uxGt9HCgco=; b=GlXs5lGMAvS7J1V9WcTRSO0uTRDccMUjQ/ZDCjdAd74PmV/S5PgdxDKA4wzXIBioFQ oGKTDX5jw2QYdXi+QMmrPNGBecitq6HbMFd+gD9jzEIzdNNGKrXZZ3hbKGUHwi84YYwI Pnc8IMomI+/A1n6AF/wJODjpIOkzpTPJ9NyOETQPlHQx8L+spbyqkpdXP+QHh1FdCHTD dIoRNnvc834dg7HMgdHTXIJQOl9bc1QuUUFpJ1HIFRP30SyU+/cPWD4CVUY61dmItJN2 Uukljrb06eBQSik9f5Ox/JJsoZskzFIV4LvKMcx4wYmIKxZqoHFZfTe8nAQ5I0F4BaUu i9wQ==
Date: Fri, 15 Nov 2013 18:02:55 +0100
X-Spam-Level:
To: bug-HTTP-Proxy [...] rt.cpan.org
Content-Transfer-Encoding: 7bit
From: "Vincenzo Buttazzo" <vincenzo.buttazzo [...] altervista.it>
X-GM-Message-State: ALoCoQmLm2JGzkdaTiGxkh/xTYr+2LMehuOeKF1GAIY+eIH2/BI3VR5yToLoGvntdmVrJVn+TirV
X-RT-Original-Encoding: iso-8859-1
X-RT-Interface: Email
Content-Length: 1364
Download (untitled) / with headers
text/plain 1.3k
Hi, we're using HTTP::Proxy to connect PHP scripts on our shared hosting with the internet. In this context a customized version of HTTP::Proxy is used to block connections to undesired domains. Things work good except for HTTPS connections because with some web servers we don't got any data back after the protocol handshake and sending POST data. After some investigation we found out that the size of POST data was related to the problem and finally we found a solution adding this line after the opening of the $upstream socket in the _handle_CONNECT function (around row 600), just after the $upstream check block: $upstream->setsockopt(SOL_SOCKET, SO_SNDBUF, $conn->getsockopt(SOL_SOCKET, SO_RCVBUF)); In fact in our context the $upstream's "send buffer" was smaller than the packets incoming from $conn, so data packets sent from PHP to HTTP::Proxy where splitted when relayed to the external website. Our supposition is that this behavior breaks someway the HTTP protocol, but the fix works good and now HTTPS works for all websites. The problem was not related to our customization because we had the same problem using a vanilla HTTP::Proxy. So, thanks for your great module, and I hope my hint can be useful for improving the module. Bye! -- Vincenzo Buttazzo Responsabile sviluppo web http://www.altervista.org/
MIME-Version: 1.0
In-Reply-To: <op.w6loa5qph9spqn [...] localhost>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <op.w6loa5qph9spqn [...] localhost>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-18314-1428848854-755.90414-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 1879
Download (untitled) / with headers
text/plain 1.8k
On Fri Nov 15 11:58:44 2013, vincenzo.buttazzo@altervista.it wrote: Show quoted text
> Hi, > we're using HTTP::Proxy to connect PHP scripts on our shared hosting with > the internet. In this context a customized version of HTTP::Proxy is used > to block connections to undesired domains. > > Things work good except for HTTPS connections because with some web > servers we don't got any data back after the protocol handshake and > sending POST data. > > After some investigation we found out that the size of POST data was > related to the problem and finally we found a solution adding this line > after the opening of the $upstream socket in the _handle_CONNECT function > (around row 600), just after the $upstream check block: > > $upstream->setsockopt(SOL_SOCKET, SO_SNDBUF, $conn->getsockopt(SOL_SOCKET, > SO_RCVBUF)); > > In fact in our context the $upstream's "send buffer" was smaller than the > packets incoming from $conn, so data packets sent from PHP to HTTP::Proxy > where splitted when relayed to the external website. Our supposition is > that this behavior breaks someway the HTTP protocol, but the fix works > good and now HTTPS works for all websites. > > The problem was not related to our customization because we had the same > problem using a vanilla HTTP::Proxy. > > > So, thanks for your great module, and I hope my hint can be useful for > improving the module. > > Bye! > >
I'm not sure if this is the best module to use for HTTPS proxying, but also you could be shrinking the size of the send buffer, making it truncate portions of the transmission. I would think that the data you send to the proxy would end up being larger than that which you received since you're adding proxy headers as well. The module `IO::Stream::Proxy::HTTPS` seems like it might be a better option for proxying HTTPS. Does this sound like gibberish?
MIME-Version: 1.0
X-Spam-Status: No, score=-6.6 tagged_above=-99.9 required=10 tests=[BAYES_00=-1.9, FROM_OUR_RT=-4, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
In-Reply-To: <rt-4.0.18-18314-1428848854-308.90414-6-0 [...] rt.cpan.org>
X-Spam-Flag: NO
X-RT-Interface: API
References: <RT-Ticket-90414 [...] rt.cpan.org> <op.w6loa5qph9spqn [...] localhost> <rt-4.0.18-18314-1428848854-308.90414-6-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
X-Received: by 10.180.187.171 with SMTP id ft11mr20502691wic.0.1428918799041; Mon, 13 Apr 2015 02:53:19 -0700 (PDT)
Message-ID: <552B920D.9010005 [...] altervista.it>
content-type: text/plain; charset="utf-8"; format="flowed"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -6.6
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id A128E24075A for <cpan-bug+HTTP-Proxy [...] hipster.bestpractical.com>; Mon, 13 Apr 2015 05:53:31 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lhrpksez80z for <cpan-bug+HTTP-Proxy [...] hipster.bestpractical.com>; Mon, 13 Apr 2015 05:53:30 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id C1E22240751 for <bug-HTTP-Proxy [...] rt.cpan.org>; Mon, 13 Apr 2015 05:53:29 -0400 (EDT)
Received: (qmail 15638 invoked by alias); 13 Apr 2015 09:53:28 -0000
Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com) (209.85.212.176) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Mon, 13 Apr 2015 02:53:25 -0700
Received: by widdi4 with SMTP id di4so65249215wid.0 for <bug-HTTP-Proxy [...] rt.cpan.org>; Mon, 13 Apr 2015 02:53:19 -0700 (PDT)
Received: from slackvista.site ([82.112.213.251]) by mx.google.com with ESMTPSA id gs7sm12001227wib.10.2015.04.13.02.53.17 for <bug-HTTP-Proxy [...] rt.cpan.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Apr 2015 02:53:18 -0700 (PDT)
Delivered-To: cpan-bug+HTTP-Proxy [...] hipster.bestpractical.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
Subject: Re: [rt.cpan.org #90414] HTTPS data transfer fails
Return-Path: <vincenzo.buttazzo [...] altervista.it>
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: cpan-bug+HTTP-Proxy [...] hipster.bestpractical.com
X-RT-Mail-Extension: http-proxy
X-Google-Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TYTyRXF1m6oj9kzwxyp+Z8AKemRtcCy50kbTnLRPB9s=; b=UZIueZCjvly9tsAbR4GaEZZ9YlHgL/2kAhh5wLYndDLWNS5iKiw9JkKpxfVJn+Rt3w /FdXnXqJythZmttSuO4iFGLt4e98eKgTOszH7nKdo77C9HXNSWJJafv2JJetgJphN7z0 57pxG+JU/6aAnYF5QsCL5pWaQtW5H5cOx6XWCZ82k0huJClYrzKfM3Q74FIAr24VIuoi FrXd9mbtH2/gkIhjByJNpyYRnQ4cxB1tu7od/3+ZURbLKi1wMkwr0FpAeQ3KAmxhedOH ddM4RF/Fh4RSDUXF3/20rUJ1Hh58yWnVY3vpQjwt153xQAKmFHsX6vqlnZJmjX1t0gfX A2Sg==
Date: Mon, 13 Apr 2015 11:53:17 +0200
X-Spam-Level:
To: bug-HTTP-Proxy [...] rt.cpan.org
Content-Transfer-Encoding: 7bit
X-GM-Message-State: ALoCoQkoWjEfQ8yi/UNpUjfsdUDltNNMn44+S9TqW43Z+mN+RAr8F5GCdNIEQTfCmj+dloto0g97
From: Vincenzo Buttazzo <vincenzo.buttazzo [...] altervista.it>
RT-Message-ID: <rt-4.0.18-23558-1428918812-333.90414-0-0 [...] rt.cpan.org>
Content-Length: 1002
Download (untitled) / with headers
text/plain 1002b
Il 12/04/2015 16:27, Michael D. Stemle, Jr. via RT ha scritto: Show quoted text
> I'm not sure if this is the best module to use for HTTPS proxying,
Maybe, but it supports HTTP and HTTPS at the same time and that's our case. Show quoted text
> but also you could be shrinking the size of the send buffer, making it > truncate portions of the transmission.
Yes, that's the other way. The important thing is that both socket's buffers have to be of the same size. Show quoted text
> I would think that the data you send to the proxy would end up being > larger than that which you received since you're adding proxy headers > as well.
Right, but the proxy first receives the CONNECT header and then opens a socket to the destination. From that point the data sent to the proxy will be passed unchanged from the downstream socket to the upstream socket and viceversa, so the buffer sizes of this sockets have to be the same to not break the encrypted stream into unusable chunks. -- Vincenzo Buttazzo Sviluppo Altervista + GialloZafferano
MIME-Version: 1.0
In-Reply-To: <op.w6loa5qph9spqn [...] localhost>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <op.w6loa5qph9spqn [...] localhost>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-1948-1429030367-1523.90414-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 943
Download (untitled) / with headers
text/plain 943b
On Fri Nov 15 11:58:44 2013, vincenzo.buttazzo@altervista.it wrote: Show quoted text
> > Things work good except for HTTPS connections because with some web > servers we don't got any data back after the protocol handshake and > sending POST data. > > After some investigation we found out that the size of POST data was > related to the problem and finally we found a solution adding this line > after the opening of the $upstream socket in the _handle_CONNECT function > (around row 600), just after the $upstream check block: > > $upstream->setsockopt(SOL_SOCKET, SO_SNDBUF, $conn->getsockopt(SOL_SOCKET, > SO_RCVBUF)); >
I've applied this change, based on my understanding of the above paragraph (a patch would have been less ambiguous ;-): https://github.com/book/HTTP-Proxy/commit/a3c2514d779d3335d947a52a614d5649bcd31bd0 Please let me know if it works for you, so that I can cut a new release. Thanks for your feedback, -- BooK
MIME-Version: 1.0
X-Spam-Status: No, score=-6.6 tagged_above=-99.9 required=10 tests=[BAYES_00=-1.9, FROM_OUR_RT=-4, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
In-Reply-To: <rt-4.0.18-1948-1429030367-1823.90414-6-0 [...] rt.cpan.org>
X-Spam-Flag: NO
X-RT-Interface: API
References: <RT-Ticket-90414 [...] rt.cpan.org> <op.w6loa5qph9spqn [...] localhost> <rt-4.0.18-1948-1429030367-1823.90414-6-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
X-Received: by 10.194.59.199 with SMTP id b7mr40697242wjr.26.1429617028157; Tue, 21 Apr 2015 04:50:28 -0700 (PDT)
Message-ID: <55363982.4040405 [...] altervista.it>
content-type: text/plain; charset="utf-8"; format="flowed"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -6.6
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 59BC02403AE for <cpan-bug+HTTP-Proxy [...] hipster.bestpractical.com>; Tue, 21 Apr 2015 07:50:40 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbjfHRaASsGu for <cpan-bug+HTTP-Proxy [...] hipster.bestpractical.com>; Tue, 21 Apr 2015 07:50:37 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id C1165240378 for <bug-HTTP-Proxy [...] rt.cpan.org>; Tue, 21 Apr 2015 07:50:36 -0400 (EDT)
Received: (qmail 12675 invoked by alias); 21 Apr 2015 11:50:35 -0000
Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com) (74.125.82.47) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Tue, 21 Apr 2015 04:50:32 -0700
Received: by wgso17 with SMTP id o17so210872970wgs.1 for <bug-HTTP-Proxy [...] rt.cpan.org>; Tue, 21 Apr 2015 04:50:28 -0700 (PDT)
Received: from slackvista.site ([82.112.213.251]) by mx.google.com with ESMTPSA id fa8sm2714358wib.14.2015.04.21.04.50.26 for <bug-HTTP-Proxy [...] rt.cpan.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2015 04:50:27 -0700 (PDT)
Delivered-To: cpan-bug+HTTP-Proxy [...] hipster.bestpractical.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
Subject: Re: [rt.cpan.org #90414] HTTPS data transfer fails
Return-Path: <vincenzo.buttazzo [...] altervista.it>
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: cpan-bug+HTTP-Proxy [...] hipster.bestpractical.com
X-RT-Mail-Extension: http-proxy
X-Google-Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=o7/knu4QrYevOx5ICtTTuVchjyY/wZCdvoobnwlDquU=; b=PTPHcevBAZze3Wdqicc1bLHGzWWvdB4o1seU1aVneZeexUwpgkGAFIvq85cMe1RAb0 51MMJ21SzEsP9lSttUvXm+XpcvGDZ8FvV+TCLQUid9S+hCJxnVoEwZjRNeMR4OaSlsKn Mez2hIyfNrPGwiPzLMCEaMbRlVkbdWQwaV6p7LQqLx/KYxu3YZ30xA4o6VpoD2FDPj1p NQ2arX8MGbVpRRQqpXIlR99Uhrmsh8EHMltjEklfBDkaZxciregP4mqhV/UAOjnlI27d p/CXdba55fT/HgumBeIzqjvrHNcgrd24KRqdEKl5V2a1Afx/ffwRleH+QTzIAz6QToyg o9iw==
Date: Tue, 21 Apr 2015 13:50:26 +0200
X-Spam-Level:
To: bug-HTTP-Proxy [...] rt.cpan.org
Content-Transfer-Encoding: 7bit
X-GM-Message-State: ALoCoQlJ0APPK+5n0ofWxj/zG4lXpJjeJEbU075I/Fhy6qEQO2nq4fDx+YM7ENTEEa2TGuoBZ+Y3
From: Vincenzo Buttazzo <vincenzo.buttazzo [...] altervista.it>
RT-Message-ID: <rt-4.0.18-8370-1429617041-775.90414-0-0 [...] rt.cpan.org>
Content-Length: 1276
Download (untitled) / with headers
text/plain 1.2k
Sorry for the late reply and the not so precise indication. Anyway that's exactly the same patch we have used in the last 2 years! Il 14/04/2015 18:52, Philippe Bruhat (BooK) via RT ha scritto: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=90414 > > > On Fri Nov 15 11:58:44 2013, vincenzo.buttazzo@altervista.it wrote:
>> Things work good except for HTTPS connections because with some web >> servers we don't got any data back after the protocol handshake and >> sending POST data. >> >> After some investigation we found out that the size of POST data was >> related to the problem and finally we found a solution adding this line >> after the opening of the $upstream socket in the _handle_CONNECT function >> (around row 600), just after the $upstream check block: >> >> $upstream->setsockopt(SOL_SOCKET, SO_SNDBUF, $conn->getsockopt(SOL_SOCKET, >> SO_RCVBUF)); >>
> I've applied this change, based on my understanding of the above paragraph > (a patch would have been less ambiguous ;-): > > https://github.com/book/HTTP-Proxy/commit/a3c2514d779d3335d947a52a614d5649bcd31bd0 > > Please let me know if it works for you, so that I can cut a new release. > > Thanks for your feedback, > > -- BooK >
-- Vincenzo Buttazzo Sviluppo Altervista + GialloZafferano
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-8370-1429617041-775.90414-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-90414 [...] rt.cpan.org> <op.w6loa5qph9spqn [...] localhost> <rt-4.0.18-1948-1429030367-1823.90414-6-0 [...] rt.cpan.org> <55363982.4040405 [...] altervista.it> <rt-4.0.18-8370-1429617041-775.90414-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-28302-1429648226-1451.90414-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 264
Download (untitled) / with headers
text/plain 264b
On Tue Apr 21 07:50:41 2015, vincenzo.buttazzo@altervista.it wrote: Show quoted text
> Sorry for the late reply and the not so precise indication. > > Anyway that's exactly the same patch we have used in the last 2 years! >
Thanks! It will be in the next release, then. -- BooK
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-28302-1429648226-1451.90414-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: API
References: <RT-Ticket-90414 [...] rt.cpan.org> <op.w6loa5qph9spqn [...] localhost> <rt-4.0.18-1948-1429030367-1823.90414-6-0 [...] rt.cpan.org> <55363982.4040405 [...] altervista.it> <rt-4.0.18-8370-1429617041-775.90414-0-0 [...] rt.cpan.org> <rt-4.0.18-28302-1429648226-1451.90414-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-26810-1433861185-904.0-0-0 [...] rt.cpan.org>
Message-ID: <rt-4.0.18-26810-1433861185-1715.90414-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
From: ppisar [...] redhat.com
Content-Length: 393
Download (untitled) / with headers
text/plain 393b
Dne Út 21.dub.2015 16:30:26, BOOK napsal(a): Show quoted text
> On Tue Apr 21 07:50:41 2015, vincenzo.buttazzo@altervista.it wrote:
> > Sorry for the late reply and the not so precise indication. > > > > Anyway that's exactly the same patch we have used in the last 2 years! > >
> > Thanks! It will be in the next release, then. >
This is in released 0.303 version. I think this bug report can be closed.


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

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.