Skip Menu |
 

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

Report information
The Basics
Id: 36709
Status: new
Priority: 0/
Queue: HTTP-Body

People
Owner: Nobody in particular
Requestors: chris+rt [...] chrisdolan.net
Cc:
AdminCc:

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



Subject: [WISH] support Content-Transfer-Encoding in multipart
Download (untitled) / with headers
text/plain 1.1k
Generally, this module works great for me in conjunction with Catalyst. However, when multipart uploading a binary file via Test::WWW::Mechanize::Catalyst, the parser gets confused (after much delving, I still can't quite figure out why but I suspect UTF-8 vs. bytes) and gets stuck at $self->{part}->{done} == 0 after over-reading the end of the part. So, my workaround is to MIME::Base64::encode() the upload and set a header of "Content-Transfer-Encoding: base64". This helps, and the parser successfully completes the part and Catalyst registers it as a Catalyst::Request::Upload instance. Great! However, HTTP::Body::MultiPart doesn't pay any attention to the transfer encoding, so it fails to decode the content and my app gets the content still Base64 encoded. Maybe HTTP::Body::MultiPart should leverage an existing MIME parser and get all of the wonderful features therein? Alternatively maybe I should ask the Catalyst folks to add decoding to their upload handling code? Or maybe the bug is just somewhere in the Test::WWW::Mechanize workflow? In the meantime, I'm think I'm going to add a check in my app for the transfer encoding and manually decode it.


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.