0

I get an interesting problem when the filename is long and contains a non-ASCII character. Here is what happens:

For this example, I have chosen the filename VeryVeryT=250°CSuperVeryFreakingVeryWowSoVeryCrazyLongFilenameWithOnlyASingleCrazyWeirdNonAsciiCharacterWhatCouldGoWrong.txt which has a single non-ASCII character.

  1. If I download this file through my ASP.NET application, the Content-Disposition header in the response is:

    Content-Disposition: attachment; filename="=?utf-8?B?VmVyeVZlcnlUPTI1MMKwQ1N1cGVyVmVyeUZyZWFraW5nVmVyeVdvd1Nv?=%0d%0a =?utf-8?B?VmVyeUNyYXp5X1NpbmdsZUNyYXp5V2VpcmROb25Bc2NpaUNoYXJhY3Rl?=%0d%0a =?utf-8?B?cldoYXRDb3VsZEdvV3Jvbmcuemlw?="

  2. If I email myself the same file in GMail and download it, the header in that case looks like this:

    content-disposition:attachment; filename="=?UTF-8?B?VmVyeVZlcnlUPSAyNTDCsENTdXBlclZlcnlGcmVha2k=?= =?UTF-8?B?bmdWZXJ5V293U29WZXJ5Q3JhenlMb25nRmlsZW5hbQ==?= =?UTF-8?B?ZVdpdGhPbmx5QVNpbmdsZUNyYXp5V2VpcmROb25Bcw==?= =?UTF-8?B?Y2lpQ2hhcmFjdGVyV2hhdENvdWxkR29Xcm9uZy50eHQ=?="

In the first case, Chrome doesn't understand the header and downloads an extensionless file with the generic name "Download". In the second case, it downloads the file with the correct name.

Firefox, on the other hand, handles the first case better but there still seems to be a problem with what .NET has constructed. It downloads a file with the name VeryVeryT=250°CSuperVeryFreakingVeryWowSo%0d%0a VeryCrazy_SingleCrazyWeirdNonAsciiCharacte%0d%0a rWhatCouldGoWrong.txt.

My application is using the System.Net.Mime.ContentDispositionclass. Here is the code that I have written:

internal static FileStreamResult GetFileStreamResult(Stream fileStream, string fileDownloadName)
    {
        return new FileStreamResult(
            fileStream: fileStream,
            contentType: MIConstants.DefaultEmbeddedFileContentType)
        {
            FileDownloadName = fileDownloadName
        };
    }

Is this really a bug with .NET or am I missing something?

Alex Sk
  • 555
  • 4
  • 10
  • 1
    The %0d%0a is a new line (\r\n) in URL encoded format which does not look right at all mixed in with that rfc1522 encoding, the format should be cr-lf-space for a multi line header. – Alex K. Jan 23 '17 at 12:26
  • This .NET 4.0 bug sounds very similar https://support.microsoft.com/en-us/help/2402064/an-email-message-attachment-name-that-contains-non-ascii-characters-and-is-longer-than-41-utf-8-encoded-bytes-is-encoded-two-times-before-transmission-in-an-application-that-is-compiled-for-the-.net-framework-4 I am targeting .NET 4.5.2 though... – Alex Sk Jan 23 '17 at 17:08
  • 1
    Tf this Content-Disposition field value appears as *HTTP* header field, it's broken. Consult RFC 6266 for the correct syntax. – Julian Reschke Jan 23 '17 at 18:06

0 Answers0