On Thu, Mar 1, 2012 at 6:00 AM, Gisle Aas <gi...@activestate.com> wrote:
> > HTTP::Headers doesn't do any encoding for you, which basically means that > you > need to pass encoded strings as $name and $value, and make sure the result > ends > up as valid HTTP. > Ok. I typically like to decode and encode at the "edges" of my code, but it's less clear to me if setting a header here is at the edge. Clearly special handling is needed in this case. > RFC 5987 seem to be relevant for HTTP::Headers to support in this regard. > > This discussion about Content-Disposition seemed relevant to your original > question: > > > http://stackoverflow.com/questions/1361604/how-to-encode-utf8-filename-for-http-headers-python-django I had read that and was left somewhat confused. There's also a lot of examples of code that inspects the user agent and adjusts the filename based on the client. I don't like that approach at all. I'd rather send down what I have and let the client decide how to handle. As a lazy programmer if I'm given a filename in an upload (or anyway by a client) and then later return it as an attachement I don't think it's any of my business to modify it other than encode it for transport. So, in short, I'm simply doing this: my $encoded_filename = uri_escape_utf8( $filename ); $res->header( 'Content-Disposition' => qq{attachment; filename*=UTF-8''$encoded_filename} ); At least Chrome seems happy with that. Oh, and on the response side, can you think of a cleaner approach than this? my $encoded_filename = $res->header( 'Content-Disposition' ); if ( $encoded_filename =~ /filename\*=UTF-8''([^;]+)$/i ) { my $name = decode_utf8( uri_unescape( $1 ) ); ... } Thanks, -- Bill Moseley mose...@hank.org
