Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Double encoding for YAML sessions #524

shumphrey opened this Issue · 7 comments

4 participants


YAML::Any delegating to YAML::XS and possibly other YAML engines, deal in utf8 octets, not character strings.

    print {$fh} YAML::XS::Dump($data);

That line in Dancer2::Session::YAML prints utf8 octets to $fh. However, in Dancer2::Core::Role::SessionFactory::File, $fh is opened with binmode ":encoding('utf-8')"

This results in a doubly encoded YAML file.

$fh does not have this binmode for reading the file and this produces broken session files.

  • Is it correct for Dancer2::Core::SessionFactory::File to set the file handle encoding?
  • Easy fix is to make Dancer2::Core::YAML set binmode :raw, is this a hack?

Personally, I believe that the correct fix is to not have binmode set in Dancer2::Core::Role::SessionFactory::File, and leave encoding up to the individual Session class.
I can create either that PR or a PR that sets binmode :raw in Dancer2::Session::YAML


I was about to do a PR that just binmodes $fh, however, YAML::XS Dump returns octects, YAML::Syck Dump returns characters. So YAML::Any fundamentally doesn't work?


We (sawyer + racke) just discussed this issue. Using YAML session is not recommended for production, so the performance gain is irrelevant. Thus we agreed on using plain YAML to avoid UTF-8 issues.

And yes, YAML::Any doesn't work in this regard.


Can we have a test for this?


yeah, I'll create a test for this today/tomorrow


I knocked up a test I believe demonstrates two issues, one, YAML::Any behaving differently with different implementations, and the other, our serializer double encoding out, and single decoding in. Test file currently lives here: ff3f1be


Resolved by #562.

@veryrusty veryrusty closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.