1. 11
  1.  

  2. 5

    This stuff is why I like the attention to detail which went into the PNG file format specification. http://www.libpng.org/pub/png/spec/1.2/PNG-Rationale.html#R.PNG-file-signature

    (ASCII C notation) \211 P N G \r \n \032 \n

    This signature both identifies the file as a PNG file and provides for immediate detection of common file-transfer problems. The first two bytes distinguish PNG files on systems that expect the first two bytes to identify the file type uniquely. The first byte is chosen as a non-ASCII value to reduce the probability that a text file may be misrecognized as a PNG file; also, it catches bad file transfers that clear bit 7. Bytes two through four name the format. The CR-LF sequence catches bad file transfers that alter newline sequences. The control-Z character stops file display under MS-DOS. The final line feed checks for the inverse of the CR-LF translation problem.

    I wish that more binary file formats did this sort of thing.

    To witness the same issue in the reverse direction: at an ISP where I was a sysadmin, a very large percentage of Support issues (early ‘00s) were from people uploading their CGI scripts and not handling text-mode for conversion from Windows. My boss at the time observed that these things were all written in Perl, which didn’t care about CRLF vs LF and the only reason it was a problem was because the kernel wouldn’t run the program because of #! parsing. We modified our (FreeBSD) kernels to also strip out \r if found immediately before the \n (and another change to let -*- perl -*- work again) and a large chunk of expensive-to-provide Support calls disappeared. Oh, and our customers liked our product more than the competitors’, because ours was easier to use (and switching may have involved more debugging; what a tragedy).

    1. 3

      I’ve been burned by FTP ascii vs. binary mode so many times I can’t count. The worst part is that I kept falling for it.

      Hopefully, future generations will be safer from the yoke of FTP than we were.

      1. 3

        Hopefully, future generations will be safer from the yoke of FTP than we were.

        We’ve had ubiquitous ssh/sftp/scp for so long that it’s been a while since I encountered this failure mode. sshd is very nearly always running on that target that I just never get around to configuring ftpd. Not to mention that it will only expose credentials anyways. I only do it if I need to be able to frequently transfer very large files.

        1. 1

          I only do it if I need to be able to frequently transfer very large files.

          Ideally this really ought not to be a use case for turning off encryption any more, since modern x86 CPUs with AES-NI and carryless multiply can, AFAIK, perform AES-GCM at >10Gbps. I can’t remember but I think openssl can benchmark AES-GCM at like 5GB/s on a 4 year old laptop i5 CPU?

      2. 0

        1992 called, they want their problems back. If you don’t have the carefully crafted set of keystrokes known as “binary” encoded in muscle-memory immediately after typing “ftp”, then you’re a newbie. Hand in your Internet card, you don’t belong here.