Skip Menu |
 

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

Report information
The Basics
Id: 86272
Status: resolved
Priority: 0/
Queue: HTTP-Message

People
Owner: Nobody in particular
Requestors: p.gackiewicz [...] intertele.pl
Cc:
AdminCc:

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

Attachments


From p.gackiewicz [...] intertele.pl Thu Jun 20 04: 17:47 2013
MIME-Version: 1.0
X-Spam-Status: No, score=-6.235 tagged_above=-99.9 required=10 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
X-Spam-Flag: NO
Content-Type: MULTIPART/MIXED; boundary="50994944-1026790204-1371716253=:15784"
Message-ID: <alpine.LRH.2.03.1306201005220.15784 [...] intertele.pl>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
X-Virus-Scanned: ClamAV
X-X-Sender: gacek [...] gacek.intertele.pl
X-Spam-Score: -6.235
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id F1DA5240E12 for <cpan-bug+HTTP-Message [...] hipster.bestpractical.com>; Thu, 20 Jun 2013 04:17:46 -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 kdMN+6NSNp+K for <cpan-bug+HTTP-Message [...] hipster.bestpractical.com>; Thu, 20 Jun 2013 04:17:44 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 54A38240E0A for <bug-HTTP-Message [...] rt.cpan.org>; Thu, 20 Jun 2013 04:17:43 -0400 (EDT)
Received: (qmail 28867 invoked by alias); 20 Jun 2013 08:17:43 -0000
Received: from smtp.intertele.pl (HELO smtp.intertele.pl) (194.42.120.38) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Thu, 20 Jun 2013 01:17:38 -0700
Received: from smtp.intertele.pl (localhost.localdomain [127.0.0.1]) by smtp.intertele.pl (Postfix) with ESMTP id 42B8F7D2FA for <bug-HTTP-Message [...] rt.cpan.org>; Thu, 20 Jun 2013 10:17:33 +0200 (CEST)
Received: from gacek.intertele.pl (gacek.intertele.pl [10.3.0.31]) (Authenticated sender: gacek) by smtp.intertele.pl (Postfix) with ESMTPSA id 198BD7D155 for <bug-HTTP-Message [...] rt.cpan.org>; Thu, 20 Jun 2013 10:17:32 +0200 (CEST)
Delivered-To: cpan-bug+HTTP-Message [...] hipster.bestpractical.com
User-Agent: Alpine 2.03 (LRH 1266 2009-07-14)
Subject: bug in HTTP::Message::decoded_content()
Return-Path: <p.gackiewicz [...] intertele.pl>
X-RT-Mail-Extension: http-message
X-Original-To: cpan-bug+HTTP-Message [...] hipster.bestpractical.com
X-Spam-Check-BY: la.mx.develooper.com
Date: Thu, 20 Jun 2013 10:17:32 +0200 (CEST)
X-Spam-Level:
To: bug-HTTP-Message [...] rt.cpan.org
From: Piotr Gackiewicz <p.gackiewicz [...] intertele.pl>
X-RT-Interface: Email
Content-Length: 0
content-type: TEXT/PLAIN; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8BIT
X-RT-Original-Encoding: utf-8
Content-Length: 1086
Hi. I think there is a bug in decoded_content() function in this package. In version 6.06, it evals such piece of code: if ($self->content_is_text || (my $is_xml = $self->content_is_xml)) { my $charset = lc( $opt{charset} || $self->content_type_charset || $opt{default_charset} || $self->content_charset || # <============= "ISO-8859-1" ); ... but content_charset() calls decoded_content() again, creating circular dependency. Evaled code silently dies then. If it is not logical error, this code should be probably rewritten. I found it trying to install CPAN XML::Twig code. It did not pass several tests using LWP::Simple, loading simple HTML via file: url. Simple patch attached, removing this call. Regards, -- Piotr Gackiewicz Intertele S.A. - operator systemów ITL.PL i DOMENY.ITL.PL al. T. Rejtana 10, 35-310 Rzeszów TEL: +48 17 8507580, FAX: +48 17 8520275 http://www.itl.pl - niezawodne serwery wirtualne http://domeny.itl.pl - tanie domeny internetowe http://www.intertele.pl
Content-Description:
content-type: TEXT/PLAIN; charset="utf-8"; name="HTTP-Message-6.06-content_charset.patch"
Content-Disposition: attachment; filename="HTTP-Message-6.06-content_charset.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.LRH.2.03.1306201017320.15784 [...] intertele.pl>
X-RT-Original-Encoding: ascii
Content-Length: 463

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

MIME-Version: 1.0
In-Reply-To: <alpine.LRH.2.03.1306201005220.15784 [...] intertele.pl>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <alpine.LRH.2.03.1306201005220.15784 [...] intertele.pl>
Content-Type: text/html; charset="utf-8"
Message-ID: <rt-4.0.13-5943-1371848674-1216.86272-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: 324
I can't see anything wrong with the current code.  The inner call to decoded_content shouid never recurse further as it's called with charset => none.

Can you provide a small test case that demonstrates infinite recursion?  I wasn't able to reproduce any bad behaviour on my own.
X-RT-Interface: REST
MIME-Version: 1.0
X-Mailer: MIME-tools 5.504 (Entity 5.504)
RT-Message-ID: <rt-4.0.18-2721-1490921992-27.86272-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: binary
Content-Length: 82


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.