The server doesn't set Content-Type header in the response.
The specification https://tools.ietf.org/html/rfc7231#section-3.1.1.5 says:

   If a Content-Type header field is not present, the recipient
   MAY either assume a media type of "application/octet-stream"
   ([RFC2046], Section 4.5.1) or examine the data to determine its type.

   In practice, resource owners do not always properly configure their
   origin server to provide the correct Content-Type for a given
   representation, with the result that some clients will examine a
   payload's content and override the specified type.  Clients that do
   so risk drawing incorrect conclusions, which might expose additional
   security risks (e.g., "privilege escalation").  Furthermore, it is
   impossible to determine the sender's intent by examining the data
   format: many data formats match multiple media types that differ only
   in processing semantics.  Implementers are encouraged to provide a
   means of disabling such "content sniffing" when it is used.

So the specification doesn't require guessing.
On the contrary, it warns against it due to possible security risks.
Chrome Chrome follows the safe route and assumes "application/octet-stream" as per the recommendation in the spec.
Firefox (and maybe other browsers) take the risks.

Exactly, this is working as intended.

For https://grooming.wahl.com/sites/default/files/products/631_1 


t=5760 [st=127]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                       --> HTTP/1.1 200 OK
                           Date: Fri, 16 Mar 2018 17:44:28 GMT
                           Server: Apache/2.4.18 (Ubuntu)
                           X-Content-Type-Options: nosniff
                           Last-Modified: Mon, 07 Dec 2015 18:56:12 GMT
                           ETag: "14394-5265369305b6e"
                           Accept-Ranges: bytes
                           Content-Length: 82836
                           Cache-Control: max-age=1209600
                           Expires: Fri, 30 Mar 2018 17:44:28 GMT
                           Keep-Alive: timeout=2, max=100
                           Connection: Keep-Alive

Makes sense, thanks for looking into it.