ok, I follow.

Note that even if it seems to work, that doesn't make what you say correct. Depending on how the client encodes the request, the OP's code will work. That doesn't make it right.

I suspect one of two reasons for the differences:

• Your client encoded the request such that the initial decoding is a no-op (e.g. it %-encodes every byte with the 8th bit set). You won't be so lucky with a different client.

• Maybe your version of decode silently does nothing (instead of dieing) when it guesses a double-decode is being attempted. If so, that will make the OP's code work for all but unlikely inputs. But that means you're relying on decode to catch your bug.

Update: Cleaned up. Replaced first paragraph. (It was "Gotcha.", which is ambiguous.)

I suspect one of two reasons for the differences: ...

Neither of those is the case.

I've verified (by sending the request through a proxy) that the content is sent UTF-8 encoded (i.e. no %-encoding).  And my Encode::decode also behaves normally (i.e. it would die with "Cannot decode string with wide characters").  This is, however, irrelevant, because CGI.pm has code to prevent double-decoding:

sub _decode_utf8 {
    my ($self, $val) = @_;

    if (Encode::is_utf8($val)) {
        return $val;
    }
    else {
        return Encode::decode(utf8 => $val);
    }
}
[download]

This sufficiently explains the behavior I observed and reported (for the input side).

Well, it's pretty damn close. I said

Maybe your version of decode

I should have said

Maybe your version of the decoder