Reputation: 393
I just finished debugging an issue for a project where an HTTP 500 would go up whenever Drupal attempted to send a file to download. Turned out that the server thought the Content-Disposition header was bad because of the filename attribute encoded the way RFC 2047 specifies, but it just wasn't having the \n. So I replaced n with r and now the server is more than happy.
So I'm wondering if this server treats \n different from \r and how I would be able to tell in the future and/or why \r would work and \n wouldn't?
Edit: The headers sent by the script:
X-Powered-By: PHP/5.3.17
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Wed, 14 Nov 2012 20:43:20 +0000
ETag: "1352925800"
Content-Length: 1302854
Content-Disposition: attachment; filename="=?UTF-8?B?UHJvUXVhbGl0ZSBNYW51ZWwgZGVzIHByb2dyYW1tZXMgcHLDqWFsYWJsZXMgMjA=?=
=?UTF-8?B?MTAgYXZlYyBhbm5leGVzXzBfMC5wZGY=?="
Cache-Control: private
Content-type: application/pdf
Upvotes: 1
Views: 293
Reputation: 53512
I assume here that you are talking about the line termination.
According to RFC2616 HTTP headers should end with '\r\n' string (CRLF):
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body
...
generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
That is what should terminate an HTTP header line. If you don't follow the specifications, the server can either choke or do something else it feels like doing, so irrelevant of the server, you should.
Upvotes: 1