If we're going to talk history, HTTP was never "designed for" file transfer. HTTP/0.9 was designed for a Gopher replacement; and Gopher was designed for information access. HTTP/0.9 followed the Gopher model: open a TCP session, send a request, read the results until the connection was closed. Gopher replies could be menus or any of a handful of other types (not really extensible). Dan Connolly gets credited with promoting the idea of using MIME to get an extensible information set. Early on, HTTP acquired content negotiation, with the addition of an "Accept:" header where the client would inform the server of its preferences for MIME types and parameters. I thought the idea came from work at PARC on "System 33", in which the server would do format conversion to meet the needs of the client (including OCR of image files or generating images from text). In general, HTTP has retained the distinction of the "resource" vs. its "representation". A "file" is a resource.
HTTP doesn't send resources, it sends representations of resources, which might vary depending on the Accept header or others (user-agent being common).
I think with a "file transfer" you might expect to retrieve enough data in response to a request that the receiver might be able to replicate the original resource and all of its representations.
Accept: text/rfc;pagenumbers=yes,text/html,application/pdf
--
https://LarryMasinter.net <- chair of the room where it happened
