Also, the 'true' pdf is reporting EOL: LF 1252 Mixed through WinMerge. A close inspection of the mismatch indicates that the valid pdf maintains what looks like a NUL 00 character in places whereas my octet-stream contains literal spaces. I re-encoded the EOLs for Unix and the diff shrank to ~1k lines out of 160k. I then ran a WinMerge comparison of it against the contents of the pdf and every line mismatched on line endings. I pulled the Message Body of the response from the server and dropped it to file. HTTP Response with an octet-stream version of same file, in UTF-8 encoding (I assume).The server sent me back an aplication/octet-stream with an attachment Disposition. DetailsĪs for my manual pull of the file, I have providedĪccept: application/pdf, application/x-pdf, application/x-gzpdf, application/x-bzpdf Some characters may not display or print correctlyĪnd I cannot work through why it can be extracted from the 'true' pdf but cannot from the one I am saving. When I open my file in Adobe Reader X, I get an error that itĬannot extract the embedded font 'LFIDTH+ArialMT'. To this point, I can save the octet-stream as pdf and I can get the proper page count and some of the page headers and numbers, but very little of the body content is loading. I have downloaded a pdf twice, once through Chrome as an experimental control once again through a raw /GET request via Fiddler which returns me an octet-stream.

Download winmerge manual pdf