

The problem probably isn't that Windows (or whatever the OS and desktop environment on the client is) isn't recognizing the content type, as Wireshark is trying to open the file the problem is probably either that: If the client is running some form of UN*X, such as Linux or OS X or *BSD or Solaris or., then the file will probably transfer without a problem with any Content-Type. The only difference that the Content-Type would make would be to the client that's downloading the file a Content-Type of application/octet-stream should work, even when transferring from a UN*X machine (as I infer your server is, unless you're using a lot of Cygwin in your CGI script) to a Windows machine (as I'm guessing the client is, from the Windows XP-style window decorations). Wireshark doesn't know the Content-Type for the file, and doesn't care what it is it determines the file type based purely on the contents of the file.

Wireshark can also read a number of other types of capture files from other programs however, the ".cap" file in question doesn't look, to Wireshark, like any type of file it can read.

Capture files written by tcpdump are pcap files (although the tcpdump that comes with OS X Mountain Lion can also write pcap-ng files). The dialog box Wireshark popped up indicates that the file was successfully "opened", in the sense of lower-level file system "file open" calls, by Wireshark, and that Wireshark succeeded in reading the beginning of the file, but it did not recognize the data that it expected to be at the beginning of the file.Ĭapture files written by Wireshark (or TShark or dumpcap) are either pcap files or pcap-ng files.
