Comment 13 for bug 740140

What's actually happening is that the SourceForge server is sending the Content-Length header twice. Here are the headers I'm seeing, as captured by tcpflow:

  GET /plugin.conf HTTP/1.0
  Host: hplip.sourceforge.net
  User-Agent: Python-urllib/1.17

  HTTP/1.1 200 OK
  Server: Apache/2.2.3 (CentOS)
  Last-Modified: Thu, 17 Mar 2011 06:58:02 GMT
  ETag: "1b8e-49ea82eb2b4d9"
  Content-Length: 7054
  Expires: Sat, 26 Mar 2011 00:02:02 GMT
  Content-Type: text/plain
  Content-Length: 7054
  Date: Thu, 24 Mar 2011 00:02:02 GMT
  X-Varnish: 1348565344
  Age: 0
  Via: 1.1 varnish
  Connection: close

This is disallowed by HTTP/1.1. RFC2616 defines Content-Length thus in section 14.13:

       Content-Length = "Content-Length" ":" 1*DIGIT

but in section 4.2:

   Multiple message-header fields with the same field-name MAY be
   present in a message if and only if the entire field-value for that
   header field is defined as a comma-separated list [i.e., #(values)].
   It MUST be possible to combine the multiple header fields into one
   "field-name: field-value" pair, without changing the semantics of the
   message, by appending each subsequent field-value to the first, each
   separated by a comma. The order in which header fields with the same
   field-name are received is therefore significant to the
   interpretation of the combined field value, and thus a proxy MUST NOT
   change the order of these field values when a message is forwarded.

My reading is therefore that hplip.sourceforge.net is in violation of a MUST in RFC2616 and the client has no obligation to work around it, although some clients (e.g. Firefox) appear to do so. This should be reported to SourceForge.